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His    thesis      ^resents    a      conceptual    view      of    a      reu 
"Software   Library. "      Issues    ccicerainj    the    "aoitwarc   cr. 
and       its      Subsequent      impact      en      software      development 
rtvieviea.  The    traditional      library    is      described    :o; 

farrcs€  ci  comparison  with  the  5oit*ar-  Library.  .4  ra 
uiar  ex  a  aj-lt  oi  the  Software  library,  tne  Pro^raa  lit 
is  lescrihec  as  a  prototype  of  a  reusao-.e  library. 
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rio^ram  library  is  described.  Ine  s^cci^i.  :-iaLu:ti-  c 
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I-    IJiJIOCOCTlCN    AND    BACKGROUND 

The  Department  cf  Defense's  (DoD)  Annual  Report  FY  '81, 
reported  the  DoD  spent  over  33  billion  on  software  with 
these  expenses  heme  projected  to  grow  to  350  hiilicn  rer 
year  ry  1SSC  [Ref.  1".  These  estimates  aia  alarmingly  hi^h; 
wnat  is  periiaps  worse  is  the  projection  chat  the  costs  o: 
software  maintenance  wiii  rise  significantly  atove  t.:e  oust 
cf    original   dcsvelo^mert. 

As  this  trend  of  increasing  software  costs  centimes, 
two  questions  come  tc  mind  :  why  are  the  costs  factors  s; 
dramatic;  and  are      the      reasons      resolvable    with      today's 

modern  technology?  The  general  response  to  the  cause  cz  the 
high  ccst  cf  software  usually  centers  on  the  highly  publi- 
cized "scftware  crisis."  The  crisis  encompasses  all  soft- 
ware related  problems,  frcm  the  simpiiest  to  the  .test 
complex.  'Aore  specifically,  when  referring  to  software 
systems,  the  reasons  for  the  crisis  focus  on  the  issues  of 
the  systems  being  norresponsive  to  user  needs,  unreliable, 
excessively  expensive,  untimely,  inflexible,  difficult  to 
maintain  and  not  reusable  [fief.  2J.  For  the  most  fart, 
these  reasens  establish  the  symptoms  of  the  ^ronlem,  rather 
than  identify  the  prcrlem  itself.  But,  since  the  prcnlem  is 
not  well  defined,  tie  solution  may  conceivably  come  through 
tne    alleviation    cf    the    symptoms. 

1c  help  solve  portions  of  the  software  crisis,  software 
tools  and  techniques  must  be  developed.  Ihe  development  of 
products  is  but  an  initial  step.  The  emphasis  shcuid  he 
placed  cr  the  concepts  associated  with  the  software  product. 
One  cf  the  more  prevalent  concepts  to  ce  addressed  is  that 
cf  software  reusability.  Because  of  its  broad  definition 
{as       defined      in      a    latter      section),         reusability      clcsely 


relates  tc   other  ccrcerto   like  commona Lty,    portability, 

nodularity,  maintainability  and  evolution.    Ihese  relaticn- 


shits  ax€  described  acre  or 


Ctiic X 


in  d  Hex  .  3  ]. 


What  lakes  reusability  sc  crucial  is  the  presunpticn 
that  a  well  understccd  ^rasp  of  c^is  concept  couic  indeed 
resolve  seme  of  the  .acknow ledged  symptoms  of  the  software 
crisis.  Tc  suggest  that  reusability  alone  could  scive  the 
crisis  is  ridiculous.  lo  use  the  concept  in  conjunction 
kith  a  f  icven  software  methodology  .vou-a  seem  zone  i^.ii- 
istic.  But  there  is  little  evidence  endt  anj  piicticia. 
software  development  methodology  along  t;.  *=se  lines  ..  a.  1 .  ..  . 
avdiiaf-Lt  ir.  the  near  future. 

I  h  e  Software  i.  i  r  r  a  r  y  z.  a  s  teen  rropos«d  as  a  c  c  n  o  *.  g  i'  u  a  a. 
software  product  designed  tc  help  solve  many  cz  the  software 
rtiated  rroriems.  Before  the  Software  library  can  .c  intro- 
duced as  a  £ossihle  sciution  tc  any  of  the  problems  incLudeu 
in  the  software  crisis,  it  must  provide  ~o  Lac  user  t..- 
anility  to  identity  and  resolve  the  many  r^a.atcd  symptoms. 
The  Software  Library  is  net  a  new  or  modern  ccncec;. 
However,  as  proposed  in  this  thesis  it  can  ne  designed  as  a 
hierarchical  library  able  to  respond  to  some  of  the  afore- 
mentioned symptcms.  The  extent  to  which  this  scftwar= 
product  can  resclve  the  bottleneck  in  software  develoraent 
is  uncertain,  but  the  potential  does  exist,  as  will  b«= 
discusse  d . 


A.       SCITSABB  LIBBARIIS 

1  -   History  of  ? i cjgr am  Liriaries 

The  value  of  Scftware  Libraries  has  been  recognized 
since  the. intr oduc ticn  of  computers  and  associated  prograis. 
In  the  early  days  of   computers,   libraries  were  mainly  used 
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as   x  €  t  ci  it  cii.es      for   commonly      used    software.  It    was      not 

until  the  latter  196C»s  and  early  7D»s,  when  the  economic 
cost  factors  (i.e.,  production  and  maintenance)  c:  software 
levari  to  rise,  that  the  significance  ox  the  Software  Library 
tecani€  highly  evident.  There  were  otxcx  ractors  instru- 
mental ix  reestablishing  interest  in  libraries:  increas- 
ingly ccmfiex  problems,  (e.g.,  mathematical;,  needless 
duplication  of  code  and  cede  which  was  isaai.y  Ice;  tr.an 
reliable.  Since  a  large  number  ox  tut  components  t;  _e 
housed  in  the  lirrar^  were  mathematical  m  nature,  j.  c  ::Jj:- 
necessai}  tc  produce  a  library  that  was  reliable,  -cr^ra". 
(axle    tc    service    a    bicad    ^rcu:    of    users)     and    accurate. 

lo  fulfill  tie  requirements  sought  xy  tne  usr_-rs  o; 
the  lixraries,  the  IHSL  (International  Mathematical  and 
Statistical     Libraries,         Hcuston,         Te^as)  and       ti.e       :;A  3 

(Numerical  Algorithms  Group,  Oxford,  Sngiandj  Libraries  ^it 
introduced.  Frcm  these  lixraries  and  others  of  this  ^_a, 
the    cencept    of.    the    Program    library    evoivea. 

2  •      A   General   Def initio n    cf    a    Program    Liorar y 

Ihe  IMSL  and  NAG  Libraries  can  be  considered  as  3*cod 
Software  Libraries,  highly  effective  in  accomrxisnir 3  taeir 
design  gcals.  That  is  not  to  say,  that  either  would  pecvide 
the  best  basis  for  defining  the  Program  Library  envisioned 
by  this  author.  To  give  an  a±.  c  ro^riate  definition,  require- 
ments concerning  today's  (1984)  technology  must  be  inccr^c- 
rated.  One  of  the  basic  demands  of  current  users  cf  a 
library  is  for  crgarized  storage,  search  and  retrieval  on 
entities  (e.^,.  ,  programs  and  their  components)  withii  the 
library.  Cther  concerns  include  txe  ability  to  manipulate 
(i.e.,  modify,  link,  update  and  list)  entities.  Ih^sa 
issues    axe    important    tecaus e    the    users      of    a    library    will   in 
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fiiiallyy  the  litrar\  should  have  su en  assets  as:  speedy 
efficj.er.cy  and  effectiveness.  Ine  requirements  mentionec 
auove,    lead    to    a    aefintion    of    a    Program    Library:  "A    stan- 

dardized ccllection  of  proven  entities  to  ce  stored, 
retrieved    and    manipulated   by    a    user." 


2  .       £t  a  tus    of    ?r  coram   L  if  r  aa^s 

A  review  of  existing  Program  Libraries  shows  that 
there  is  wide  variability  in  ^uaiity.  According  to  [Ref.  4] 
the  5hA:Z  Program  Li^rar^  represents  a*.  ur.rtiian  j.e  scurc^  :i 
software.  Even  though  the  library  provnes  ma:.  ^  jc:i;'.  a;.. 
Si.areatie  routines,  the  number  of  routines  */:, ich  rail  L  . 
work    as      advertized    is      unacceptanily    nigh.  On    the      ctr.er 

extreme,  I  ?.SL  provides  a  library  that  is  ii^x.  succ-ssfj-.: 
a  prccranmer  whe  nas  the  resources  oz  the  I15L  Library  is 
literally  wasting  time  and  coney  if  he  or  sis  rosozes  :o 
writing  software  which  performs  any  or  the  proven  functions 
supplied    by    IMSI. 

/iith  the  success  of  the  iilSL  and  similar  libraries, 
why  has  there  net  been  more  widespread  use  of  the  Program 
library?  Vihy  is  research  on  Program  Libraries  virtually 
nonexistent?  The  economics  involved  could  he  part  ;:  the 
reasoning  cr  possibly  thfere  is  a  iacx  of  understanding  of 
what    a    truly   yuality    library    should    offer    a    user. 

^  •       Evaluation    of    Pro^r am    libraries 

Ihe  significance  of  the  Program  Library  has  been 
emphasized  ever  the  fast  20  cr  so  years,  but  still  there  has 
not  teen  signs  of  grewtn  in  the  number  cf  libraries.  Ihcse 
Program      Libraries     (cr      similar    software      tools)        that,     nave 
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proves  tc  be  efficient  and  cose  effective  nave  iOuii:<iteC  cue 
computer  industry  and  nav^  estaclisned  guidelines  roc  future 
developmental      software.  Bice    and      Schwetaar      si.,:  esc      in 

[Eef.  4],  that  there  are  at  least  three  requirements  «..iC. 
should    he    present    in    any    quality    11  b  r  a  r  y  : 

1.  A    large    supply   of    useful,    reliaoie    parts 

2.  A    catalog    of    parts,     nakirg    them    easy      to      locate      an i 
evaluate,    and 

3.  A    mechanism    fcr   connecting    rarts    together,    sc      a?      to 
icrr    more   complex    oojects. 

Using  taese  requirements  as  an  evaluation  tcoi,  ■'.:. 
evaijuaticr.  sea e ait,  as  shown  in  larle  I,  can  be  iJi;  cc  ra:< 
existing    lirraries.  Tne    requirements    ao      enumerates     :::v- 

are  net  all  inclusive  and  without  economic  justif icaticr.  [in 
time      and    meney)  the    library      can   not      be    ful^y      evaluate.: 

against  these  or  any  other  requirements.  with  est  ah  lisbi-d 
nifetneds  cf  evaluating  Program  libraries  and  economic  L^a^z.-.^ 
justifying  tuture  developments  in  this  area;  why  na.  twis 
not  teen  practiced  mere  widely?  In  seeking  the  answer,  this 
thesis  suggests  that  many  cf  the  motivation  factors  (i.e., 
reusability,  portability,  generality,  etc.)  nave  not  been 
completely  understccc.  Once  tnese  and  ether  issues  ai-r 
incorporated  ante  the  evaluation  scheme  ioi  quality  Program 
libraries,  the  motivation  necessary  to  design  these  and 
ether  software  products  can  be  better  understood.  Seme  oz 
these  irotivation  issues  will  be  explained  in  this  thesis, 
hopefully,  this  will  benefit  the  future  developmental  sort- 
ware    products. 


E.        ICC  JlCillCS    OF    THE    EOEIWAHE    IIBBARY 

It    nas    teen    stated   in  [fief.    5 ],    that    by    1990    there    could 
be    as      many   as       1.2    nillion    programmers      in    demand      with    the 
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TABU    I 
Evaluation   of    Program    Libraries 


TYPE 
LI  Br  JJi 


T ,T 

1  EZCjUIR  E-     |  EMINuS 
I     j  H  E  NT  S  J 


13  £1 


iNAG 


UK  IX 


5  £  Li  A  3  K  S 


when    used    with    mat  neiia  t 
oal   ana    statistical 
applications 


Available,     Lit    not 

tC      lOCdLd      10  J  tl  iica 


e  a  s  v 


Eds    no    in  t  er  ccn  r.ect  ion 
scheme,    a«rtr.ds   on    out- 
side   ~r  o .ran nin  . 


Primarily    roc    uSi..-"  2  ti~ 
Cdl   a n g    statistical 
a.-  t-iications 


&as    its    own    mcexing 
scheme/     rfhic:;    is    accci;* 


tie, 

IcdadD. 


artiaily 

or  m' 


Has    built-in    imxin 
mechanism 


Has  large 
mands  and 
various  a 


i-, 


n u m Jj e r  01  cci 
programs  ror 

r  ? 


1  c  a  x  1  o  n  s 


Available  in  manuals  and 
KWIC  indices 


Uses  pi  3d  mechanism  as  an 
interconnection  scneme, 
tut  only  for  single 
streams'or  characters 


^Characteristic  ratings  as  follows: 
£  -  Zxcellen  t 
A  -  Average 
t    -    Poor 


actual  supply  or  catarle  programmers  tailing  to  rise  fast 
enough  tc  close  the  gap  between  supply  and  demand.  hhile 
this  situation  only  represents  a  small  portion  or  the 
overall  crisis,  there  would  seem  to  be  enough  or  a  ^rcoiem 
to  warrant  aore  concern  tha n   is  presently  exhibited.    what 
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;ic  a n  -i 


e  x  f  c  r  t  .<= 


to 


appears  even  acre  as  tcnisni  eg,   is  tne  fact  tna 

ether   problems  nave   not   resulted   in  massive 

devticp  software  products  which   could  fcsii^i;  resolve  sc^c 

ex  the  problems  ox  supply  and  demand. 

As  cited  on  r.umercus  occasions,  the  So  it  ware  Litraij  has 
arcund  fox   a  rumbex   of  years,    nut  yet   it  nas   not 


of  product   cap axle 


;of  t  wait    c  r  is  is 


xeen 

sign iiic ant iy    evcived      into     the    t 
resclvirc    any    of      the    major    effects    of      t. 
In is      could    he       due    tc      the      iacx.    of      Sort* are   Lirranes      n 
mdustxy.       Sc,     why    au    they    so    scarce?      It    could    he    tnat    the 
concept    ci    a   Software   Library,         more    specifically    a    ;::,.!.: 
Library/       fails      to    ^rogtct      substantial    savings       (^..e., 
time,      in    icney    or    i  r.    productivity)       to    the    user.  Ic    cc:13 

also  he  that  eacn  organization  is  waiting  ror  the  cc.;;;  to 
take  the  fixst  step.  Of  ccurse,  it  could  re  due  to  soini- 
tning    ether    than      any    issue    aiscussed    thus      fir-  7c    puxsut 

tne  question  even  further,  cnt  must  wonder  if  cne  concept  >1 
a  reusahie  Program  Iihrary  will  actually  reauct  the  amount 
cf  redundancy  in  prcgram  writing.  Or  will  tne  tme  spent 
sear  chine  for  existing  iihrary  components,  outweigh  any 
savings?  Ihese  are  tut  a  few  ox  the  issues  that  nay  aav«= 
lessexed  irtexest  in  evolving  the  Software  Iihrary. 
Although  the  economic  pitfalls  oi.  a  software  product,  m 
this  case  the  Software  Library,  may  never  he  fully  realized 
cr  resolved,  it  is  still  the  responsibility  of  the  designer, 
tiie  in|  lementor  and  the  user  to  insure  that  tne  many  ques- 
tions   surrounding    the   economic    issues    nave    neen    addressea. 

Cnce  there  is  a  tetter  understanding  of  reusability  and 
the  Software  Library,  there  can  be  a  more  widespread  use  of 
the  cencepts.  That  is  to  say  that  certain  issues  such  as 
time  spent  reproducing  and  testing  a  program  can  he  tetter 
utilized.  There  'are  other  economic  issues  each,  affecting 
the    software      crisis    in    some      unig-ue    manner.  The    eccnoiic 
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issues  ait  ii^ortant  to  the  future  of  software  develop  ier.t . 
An  understanding  of  the  prcb^em  is  not  encugn  to  solve  me 
^roDiem,  tut  with  the  implementation  of  such  ccr.cirti  as 
reusability,  the  software  crisis  may  fce  reduced  tc  a  ^cr^ 
manageable    i.robiem. 

1  .       Feu sab iiitv    aid    Port ability 

Cf  tiie  nany  cotiva  tiers ,  drj.vir.ij  tne  neei  for  _ 
Sort  ware  iirrary,  there  ax  €  two  vtij  closely  r  =  ji  i ;. 
not i ens.       They    are    p citabilitj    ana    reusability.  I:.    c(;-.i\.;.. 

a   r  e  1  a  t  i  c  Pi  s  hi  o    **  h  i  c  ii    [cot      cjcti-iitics    tne    w  i  o  s  e  r  e  s  s    t  -. : «  ^  -. . 
trie    t  v.  c    ccrcepts,      tie    following    represent  a  iici    seers    a  t  t  _  :- 
priate:      reusability    should    re      considered    a    necassar^, 
not    sufficient       condition   for    portability.  Ibis,      s.-.c-s    tae 

relative  u^ortaDce  cf  reusability ,  however  each  corci-t 
uiii    be    discussed. 


a.       Reusability 

Reusability  nas  been  identified  as  u  key  tc  the 
effectiveness  of  the  Software  Library  and  as  a  concept  ic: 
helping  to  solve  the  previously  mentioned  software  crisis. 
Unfortunately,  there  is  not  one-  unique  definition  tc  su:t.crt 
trie  ccrcept  of  a  Software  library  associated  with  reusar^e 
software  issues.  Therefore  to  estar^ish  a  basis  fcr  under- 
standing, the  following  definiticn  will  be  used:  "Software 
resources  of  a  capital  nature  which  are  used  m  the  deveicp- 
lent  cr  maintenance  of  software  products  with  er.d  uses 
different  from  that  cf  the  cemponent  resources."  Farther 
ciar if icaticn  also-  provided  by  the  reference  encompasses  any 
infomaticn  generated  at  any  time  throughout  the  software 
life-cycle.  Also,  a  component  resource  is  described  .as.  a 
Etodular  product  of  tie  software  life-cycle,  possessing  the 
charac teiis tics    of    bein^    highly    conesive    [ Ref .    6]. 
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In  [Eef.  6],  the  author  presents  a  list  ci  major 

factors  which  dictate  the  usefulness  of  reusable  software. 
Ihe  greatest  concern  is  that  acceptance  of  a  product  would 
rot  he  fcrthcomirg  if  tne  product  is  not  understood.  Inus, 
ir  a  product  does  net  appear  easy  to  use  and  economically 
reasitle,  then  there  would  he  little  desire  to  understand 
it.   A  product  can  net  prov-e  itself/  if  it  is  not  usea. 


Since  tne  concept  of  "reusi. 


sort  ware    :.as    Le< 


around    fcr    so    long,     technological   improvements    in    this    rieli 

should    re    researched. 

sents    a    source    to    re    used      as    a    guice    zor 

cf    reusarle    software. 


he    conceptual   Pro 3 ran  Library    r  c; 


^.  -z.    .  ^  — 


r.   Portability 

The  concept  of  portaniiity  nas  existed  n:>c^  :;.- 
discovery  that  larce  savings  can  be  realized  ::c:  tne 
distribution  of  good  software.  But,  as  touched  or  ty  Jc^n 
Eice  [Bef.  7],  the  dissemination  of  quality  software  is 
opposed  by  formidable  carriers,  sucn  as  the  dependency  or 
software  ce  machines  and  tne  idiosyncrasies  of  compilers  and 
c^eratinc  systems.  Iven  though  Rice  was  referring  spec-.ri- 
cally  tc  numerical  computation  software,  his  ccmierts 
warrant  consideratio-r  dj  any  organization  contemplating  tne 
development  and  transportability  of    a  new  software  rrcduct. 

Portability  deals  with  tne  designing  cf  a 
product  that  will  mirimize  the  amount  of  change  required  to 
nove  the  product  from  one  environment  to  arc t her. 
Portability  also  taJ^es  into  consideration  most  issues  of 
compatibility  which  affect  the  transportability  of  a  scit- 
*are  product. 
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The      Pro  eras    'Library,      w^iie      rot 
designed    as    a    rortarle    software      rroajct,       should    nave-    capa- 


bilities  consistent    wit. 


i  o  r  t  a  i  r  j.  1  t 7    issues. 


.e    itic 


is  that  portability  issues  represent  a  iora  or  enticement  to 
the  user.  After  ieinj  influenced  to  use  a  product  its 
benefits  can  be  tetter  understood.  Tajs,  the  added  facility 
of  portability  can  be  treated  as  a  motivational  concept  :c: 
helping  the  conceptual  Program  library  resolve  some  cr  th« 
.lobieis   inherent    to    the   software    crisis. 

Tne  environment  cr  tne  Program  Lir-rarj  arc  tc. e 
user  s.culc  determine  which  concepts  require  tr.  €  ::.-: 
eiipnasis.  In  an  attempt  to  reduce  tne  directs  ::  the  sort- 
ware  crisis  DOth  concepts  (porta fiiiity  an;  reusability; 
should  te  considered  essential  to  trie  user  cr  the  Program 
library . 


2  •       S  t  a  n  da  r  d  in  a  t  i  c  n    of    the    Software    L i r  r  a  z  y 

The  efficient  and  effective  understanding  cr  soft- 
ware products  writter  by  others  is  one  of  the  critical  prob- 
lems   in    software    development.         :iuch    of    tne    labor    expense    in 


software    development    is    involved    in    the    understandin 


r  the 


various  software  products.  One  approacn  to  this  prcriem  has 
been  tc  apply  standards  to  software  products. 
Standardization  allows  people  who  are  ramiliar  with  parts  cl 
a  software  product  tc  more  easily  become  familiar  witn  ctner 
parts.  Some  or  the  areas  of  concern  to  standardization 
include: 

Forma t 

Documentation 
Sp  e  ci  f ication 
Test  Plans 
Error  Handling 
Modularity 

IS 


lie  standardisation  or  products  a^AcS  it  raster  [cnz 
thus  u.  ere  efficient)  to  understand  a  sort  ware  product  ere 
has  net  seen  before.  3ta ndar ligation  is  critical  tc  the 
Software    Litrary: 

1)  iz  users  other  than  the  originator  are  to  easily  ac- 
cess   and.   retrieve    iteis   in    the   Lirrary, 

2)  ii  items  in  the  library  are  to  ue  incorporated  without 
cnar.ge  intc  other  iar^r  standardized  software  r:c- 
uc  ts , 

3)  and  if  the  library  is  to  oe  rui^t  and  i  air  tamed 
efficiently. 

Since  standardization  rtJitSc.  ts  sacs.  a  crit^c-a- 
aspect  ir.  software  develop  i en t  tnere  sneuiu  re  saiajeiert 
aechansas  established  tc  enforce  standards.  Tnese  iec na- 
nisms shculd  not  discourage  the  use  of  the  library,  irsteaa 
ti.ey  should  suggest  an  ease  of  ust  preferable  tc  writing 
cne ' s    cwe    cede. 


3  .      Reliability    ir    a    So  f  tw ar  e    Library, 

"The  ever-increasing  expectations  and  ne«=ds  ef  large 
organizations  and  the  advent  of  large,  chear  memories  has 
led  tc  the  creation  of  ever-  larger  information  syst^ns. 
Cne  cf  the  results  has  teen  the  discovery  that  while  a  small 
system  '  could  often  be  thoroughly  tested,  for  all  practical 
purposes  large  systems  of  interacting  Hardware,  software  and 
people  could  be  rendered  useless  because  of  unreliability. 
Since  the  physical  and  economic  consequences  of  information 
systems  failure  may  te  very  great,  interest  in  reliariity 
has    grcwr    also,"   £Ref.    8]. 

Cne  definition  of  reliability  round  in  [Eef.  8] 
suggests  the  following:  "a  piece  of  software  tnat  is  correct 
with    respect   to    stated    reguirenents      and    tnat,      further,      is 
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a^le  tc  withstand  unanticipated  demands  as  «eii.n  Ieiar.i.i 
ior  reli acidity  late  tacx  a  number  of  years  tc  wh en  usage  cf 
the  Scitidre  Liniarv  began.  Ihe  primary  conccius  then  »ere, 
tnat  the  library's  reliability  be  exhibited,  ir.  its  accuracy 
and  Id  its  aatheoa tical  stability.  Ihe  need  for  reliability 
in  a  Software  library  has  not  Changed  over  time,  tut  tnere 
is  little  evidence  that  software  deveicfient  has  let  these 
demands  with  2 ore  reiiarie  Software  Libraries.  Ir. e  finan- 
cial investments  and  research  in  software  development  s^^zz 
tc  jici  slowly,  even  though  the  reasons  just  if /in-  sue.  a  ;. 
investiert  seea  overwhelming. 

kith  a  rerewsc  belief  tnat  there  is  a  ;.  crj  icr  =•  „c. 
teixdiic  software  prcducts,  ai±  tnat  will  Li  ue-u.-rti  1  = 
product  that  will  suggest  economic  reasons  for  industrs  ana 
LoD  tc  invest  in  further  research.  Ihe  conceptual  :■;:■*::  • 
Iiorary  crcposed  by  tha.s  thesis  will  no-efui.i}  infiltree 
such  interest. 

4 .   Generality 

Por  a  Software  Library  to  support  the  concept  of 
reusability,  its  design  and  the  design  cf  the  con-cnents 
within  its  structure,  must  offer  a  certain  amount  of  gener- 
ality. Parnas  £Ref .  9]  states  that  software  can  be  consid- 
ered "general"  if  it  can  be  used  without  change  in  a  variety 
cf  situatiens.  Thts,  the  concept  of  reusability  which 
emphasizes  modification  (i.e.,  change)  represents  a  cenfiict 
Kith  the  cencept  of  generality.  Parnas  also  states  that 
software  can  be  censidered  "flexible"  if  it  is  easily 
changed  tc  be  used  in  a  variety  or  Situations.  This  ncticn 
cf  flexibility  is  more  consistent  with  reusability. 

Eased  on  Parnas'.  definitions  the  best  way  of 
achieving  generality   in  a  proposed   reusable  product   is  to 
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or  balance  between  tne  cciiCc^t:  or  -,r:.ci  5xit; 
and  ile x ibi lit y.  lae  actual  balance  is  between  the  run-tine 
coses  to  be  paid  for  generality  and  the  design-cost  inherent 
to  flexibility.  Th€  designer  of  a  software  rroduct  lay  net 
readily  find  this  balance.  But  if  he  or  she  taxes'  a  censci- 
enticus  effort  at  deciding  this  issue,  a  resulting  reusable 
product    vill  be    core    achievearle. 


C.        GOEEAI    DEEINITICiN    Of    A    SCETRARE    LI3EABY 

Per  the  most  part  the  Software  Linrary  ana  the  issues 
surrounding  it  have  stressed  code  oriented  goals.  abide  :.-.-..- 
Software  Library  is  designed  tc  support  Vdiioas  :  cross  z. 
code,  tc  center  on  this  aspect  is  not  consistent  with  the 
expectations  of  the  cverail  software  product.  Ihe  Software 
library  will  serve  the  user  and  his  organization  best  if  it 
is    defined      in    a      Dreader   context.  The    rirst      ster    is      to 

insure  that  the  semantics  of  the  term  "entity"  include  docu- 
mentation, specifications,  designs,  requirements  and  test 
plans,    as    well    as   code. 

Ihe  acre  general  definition  of  a  Software  Library  is  "a 
standardized  collection  cf  reusable  software  prccuctb 
designed  tc  enhance  economic  savings  through  tne  manipula- 
tion   and    modification   of    its   reusable    entities." 


C.       SlBQClDfiE    OF    THE    1HESIS 

Chapter  II  discusses  the  automated  traditional  library. 
Since  the  user's  r eguiremen ts  for  a  traditional  library  are 
similar  tc  those  for  a  Software  Lmrary,  this  chapter  gxves 
some  insight  into  the  functions  of  the  conceptual  Prcgran 
library.  Chapter      III      presents      criteria     'to      assist      m 
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:eco  g  r.i  z  in  g    quality    Software    .iirarii. 


s  m  >  -  a  r  e  s    vsiicus 


existing    Software   Liixarj.es      and    suggests    how    the; 

used      to      establish      guidelines        for      Mature      devei cp c en ta^ 

libraries,    specifically    the    Program   Library. 

Chapter  IV  introduces  a  hierarchical  representation  or  a 
Program  Library  that  is  ariixe  most  contemporary  Program 
Libraries.  The  discussion  stresses  how  this  structure  can 
improve  the  library's  operation  with  regard  to 
reusability.  Chapter  V  describes  a  amplication 
Its    cesicn      consists    cf    progran 


■  r  r  -*•  ■*■  »"*  - — « *•    3  =  r.  crate 
generators    structure!      l :; 


hierarchical      fasnior    at      a    level      hi:;ner 


i.  -1  . 


Itvd    in    the    Program    library.       I  his    cnapter    will    ex:- 1  a. 
this . software    product    will    assist    the    as^r. 


Chapter    VI    outlines      an    on-line    metn cd    or 
retrieving    entities      in    the      Program    Library. 


w  —  a  i.  >_  . .  _ 


-£■ 


Reference   Guide   discussed   in  tnis   en a, 


ter   re^rese 


manageable  interface  between  the  iinrar^  and  tne  use:,  In 
Chapter  VII,  the  programming  language  Ada  is  provide!  as  an 
existing  language  capable  of  meeting  some  of  the  require- 
ments of  the  conceptual  Program  Library.  Many  of  tne 
concepts  in  Ada  are  still  bein^  researched,  nut  in  gereral 
Ala  is  a  language  with  potential  useruiness  for  a  Program 
library . 

Chapter  VIII  discusses  how  the  concept  or  a  Software 
library  can  be  extended  to  non  code  software  products. 
Ihese  products  include:  documentation,  requirements,  speci- 
fications, designs  and  test  plans.  Cnapter  IX  is  the 
concluding  chapter.  It  ^resents  a  general  overview  of  the 
thesis. 


zz 


II.  THE  AUTOMATION  OF  TEE  IE ADIIION AI  IT3RJEY 


The  traditiorial  library  represents  a  wealth  oi  knowledge 
in  the  icr ic  of  books,  journals,  serials,  reports  ar.d  so 
forth.  Iherefore  the  concept  behind  the  automation  ox  sue;, 
cassivs  resources  presents  the  stiffest  of  challenges  tc 
modern  technology*  Tne  complexity  of  the  challenge  is 
increased  tecause  of  the  usual  opposition  to  the  charging  or 
a  so  called  "working  system."  To  address  this  resistance  to 
change, 
librarv  isers  will  be  stressed 


an  aspect  oi  automatic:;  leiciiCxil  to  librarians  a.* 


lie  aspect  or  interest  is  the  application  o:  ccaputers 
to  infcrnation  processing.  A  specific  concern,  familiar  to 
the  Scit^are  Library,  is  hew  tc  rrocess  the  data  needed  ror 
contrcl  ever  and  for  access  to  information.  Another  ccrcerr. 
is  in  the  approach  used  ny  an  inai vidua!  to  interact  *itn 
the  cemputer  system.  Existing  and  future  technology  accom- 
panied hy  convectioral  practices  within  the  iirrary  snould 
produce  products  able  to  respond  to  these  and  ether 
concerns.  These  issues  are  resolvable  given  an  adeguate 
understanding  of  the  distinction  between  requirements  ana 
the  actual  design.  The  gist  of  the  distinction  is  tuat 
requirements  are  independent  of  any  specific  desigr  for 
iapleaentation .  To  convince  the  skeptics  of  the  future  of 
autcmaticr  within  the  library,  the  basic  criteria  associated 
with  existing  library  services  should  be  discussed.  The 
traditional  library,  as  it  stands,  may  not  provide  all  the 
services  expected  of  an  automated  system,  therefore  tc  view 
tne  library  in  the  ccrrect  i-ersp^ctive,  issues  other  than 
speed  and  efficiency  should  be  introduced.  Prior  to 
discussing  .futuristic  criteria  fcr  an  automated  system,   the 
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expected   iur.ct.ions    oi      tne    library,       as    v^e«<=a 
bust:    he    described. 


tCt 


i  <:  L 


1  •       5cc,  uireaents    cf    tne    A_y_t  ciated    traditi.or.ix    ii£c.ajr; 

lo  the  average  user,  tne  Automated  traditional 
library  is  somewoat  cf  a  remote  concept.  Thus,  tc  lesser. 
i;.is  it£c€  or  remcteress,  tne  k  n  o  w  j.  e  c  g  *  ^  ^  c  c  c  r.  ~^.= 
librarian  (since  he  cr  s4ie  is  in  constant  contact  *-.th  tne 
user)  arc  tne  engineer  (vihc  has  designed  lar.  j  =utc»d;e: 
systeis)     is    required.      In  a 


uriost   is 


,nmt     tnis 


e  ^  ^  -  i  n  t  c  a  con  Celtic  eii  or  t  for  tn  <=  de  s  j.  a  c  -  a ._  :i:ic„v;.';- 
t^on    c:    the    most    effective       user-friendly    system.  E;2.-=ed    :\ 

research  ci  user  needs  ana  cr  the  interests  or  r. :.  e  .  s  -.  _ , 
ti^ere  siiculd  Le  some  fern  of  communication  network  tying  tne 
user  tc  an  automated  catalog  and  other  bi.riio3  rat  nic  tccis 
related  to  a  xar^e  lihrary  cr  a  system  cf  libraries.  Or.Ct  i 
text  is  identified  there  should  ce  guicx  deixverj  Cc.\- 
hility.  There  snould  definitely  ne  some  fcrm  of  user  inter- 
acticr  kith  the  system,  thus  providing  responsive  juery 
services  to  the  user  while  he  or  she  attempts  to  make  series 
cf      rapid    and      repeated    searches.  Zase    of.      access    tc      tne 

inforiaticn  must  re  provided  by  terminals  (local  ana 
remote).  Finally  the  system  should  display  detailed  infor- 
matics cf  a  text  and  trior  to  responding  tc  a  reguesc  :cr. i 
hard  copy  tne  system  should  provide  to  the  user  the  ability 
to    view    cages   of    selected    works.  An    important    point    to    ce 

stressed  is  that  the  functions  desenned  atcve  are  net  to  be 
thought  cr  as  independent  functions,  instead  certain,  if  act 
ail,    are    interrelated. 

Kith  the  requirements  of  tne  automated  system  as 
suggested  above,  the  selection  of  rerrormance  criteria  rrom 
tne    users      point    of    view      can    new      be    presented    in      the    next 
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secticr.  s.  It  must  re  rceat.;a;izea  tnat  tnese  Jiiterio  ar- 
cnly  tc  be  looked  upcn  as  guidance  towards  ij-iiiiiiv.  ths 
suggested  requirement,  and  a;  r^Jireaeics  charge  sc  dc  the 
perdcraar.ee  criteria  (tnis  suggests  the  need  ior  flexibility 
in    design) . 

2.      Associated    Performance    Criteria 


as 


Ihe      performar.ee      criteria    which      are      suggested 
tfein3    secessary    to    the    user,    include    cne    following: 

us€r    interacticr    with    ccuputir 

aids    to   browsing    textua^.    information 

a    user-indexed    library 

access   to    different   levels    or    information 
cc rrmur.ica tion    fcetweer    reiote    soirees 
extensive    software    tocis 
7)     ra^id    response    time 

Aitrough   each      of    the      aforementioned    criteria      is    a 
major    cencern      tc    the    user,       it      is    not    within    the 


remain  consistent  Kith  the  overall  purpose  (i.e.,,  the 
disc u ssi en  of  the  cence^tuai  Program  Library) ,  only  che 
perf crmarce  criteria  associated  with  .  the  user  interaction 
with    the    ccirputer    wild    be   discussed    in    any    detail, 

Ihe  interact icn  reguired  between  the  user  arc  the 
Aatcmatcd  traditional  library,  s.uouxd  not  he  thought  cf  2.0 
removed  frcm  the  control  of  the  librarian.  Ihat  is  tc  say, 
the  librarian  is  an  integral  part  of  the  automated  system, 
lo  be  mere  specific,  the  librarian  exists  is  a  reference 
source  capable  cf  prcviding  expert  reference  assistar.ee  in 
specific  disciplines  where  detailed  knowledge  is  required. 
He    or      she    would   also      be  expected      to    have    access       tc    ether 


librarians,      thus    increasin  g    t 
en    a    civ€i    subject. 


degree  O-  a^Cail  aVdila^ic 


The    tnargie    created 


*    J    C    1. 


tre 


the    librarian    and      tic    automated    system    ace      em^nasis    tc 


need    icr    an    effective   comnurica ticn    retworx,      and 


w  U  i.  c  , 


tue    r.eed   fci   a    user/librarian      interaction    with    th€    cenputer 
tecones    acre  essential. 

Present  day  technology  sa^csts  that  the  termnal 
keyboard  is  the  most  adequate  f era  of  interaction  cetv.ee.. 
the    autcnatcd    liirai",    system    and    the    user.  in    kte,.  m  -    »it 


the    nctj.cn    cf    simplicity, 


c n i  v    a    xiuiiceu    n u m r e r 


t  er  icir.a^ 


ceia t € 


r  urct i o  r.s 


ill      -e 


iae 


a   ~  -  -  ■£  w 


IRef.     10 ;, 


a    xi^ra  ridii      with    aspirations 


a  ti  c  n  ,    i.  - 
t:  ^rcvide 

L'li   CO  ■; 


unitr  the  definition  cf  "programmed  interrogation 
presentation  of  the-  term  programmed  interro., 
suggests  six  major  "process  control"  jte'js  used  t: 
the  user  with  an  initiau.  set  cf  choices  at  a  console, 
six'  keys  are  consistent  with  the  terminal  related  functions 
suggested  hy  this  thesis.  Therefore,  the  functions 
presented  will  be  briefly  described  with  Swanson's  concepts 
in  mind. 

Ihe   first  function   necessary   ror   a  good   wcrxinj 

environment  is  labeled   "specific  work."   Its  purpose   is  to 

identify  the  reguest  for  a  specific  rook,   journal  oi  zepcrt 

ty  means  cf  author,  title,   publisher,   or  other  descriptive 

(non-subject)  information. 

The  next  function  labeled  "subject  selection" 
permits  retrieval  of  material  cased  on  subject  classifica- 
tion,  index  or  keywords.  It  also  aliows  retrieval  of 
specific  information  and  finally  it  permits  browsinc  ci  the 
above  infer  nation". 
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Another    function   labeled    "previous    stlccuc;."    aiiCws 

the    user    the   anility    to    select      a-ry    idteriai    ne    or    an\     ct^er 
specified    person    a  as    used   before. 

Ihe  "similarity  selection"  is  another  :"uLctic:  isei 
to  initiate  a  chain  ci  bibliographic  citations  that  satisfy 
specified    wcrk. 

Ihe  functior  laoeied  "combination"  allows  the 
linking    ci    any    ti.o    functions. 

Ihe    next    function    is      lare^ed    "sequence    display"    ic; 

its    ability    to    step    the    display    from    one    display    tc    another. 

A  final  function  xabeied  "microtia :;.  view"  is  used  tc 
ca.il  fcr  a  micxcfiln  "display  of  Sciectca  fc;crtioES  :i  an: 
•»orx    idertified    en    tie   CRT    dis^idj. 

Ihe  function  lards,  as  uesenbed  arove,  art  rot 
designed  to  surest  an  ail  inclusive  view  or  the  terminal 
xe/j-caro  necessary  tc  rrovide  user  interaction  with  the 
system.  Hut,  wnat  it  does  suggest  is  a  selection  cr  func- 
tions considered  hasic  to  the  operation  of  the  Iirrary. 
Cnce  tie  inquiry-response  interaction  has  been  effected 
between  the  user  and  the  automated  system,  a  basic  icriat 
(possibiy  based  on  tie  bibliography)  can  be  established  as  a 
guide  cr  training  device  in.  the  use  of  tne  system.  a'ith 
this  guide,  the  user  has  an  example  of  the  response  received 
from  a  properly  formulated  mguiry.  Issues  in  regards  to 
wnether  an  inquiry  is  too  broad,  too  narrow  or  too  ambiguous 
should  become  mere  ctvious  as  tne  interaction  beccire  mere 
frequent.  The  underlying  result  is  that,  the  user  iitioves 
en  his  or  her  level  of  understanding.  Tne  Automated  tradi- 
tional library  once  understood,  coula  oe  used  effectively  as 
a  tocl  fcr  increasing  the  researcn  potential  of  the  user  and 
cf    the    librarian. 


Ill-    CHARACTERISTICS    RZIAIIVE    TO    A    2RCGRAM    LIERAS'i 


A. 


E2IS1ING    CHARACTERISTICS 


Two  organizations  have  produced  large,  -ortabie,  gcod 
guaiit}        aid      inexpensive        libraries.  They      are         I.:s_ 

(luterndtioiidi  Mathematical  and  Statistical  lii.i::^, 
Houstcr,  Texas)  and  NAG  (Numerical  Algorithms  Group,  Z~azql2, 
England).  Both    libraries      are    evaluated      with    r^Ji::      to 

their      existing      characteristics        a^d      t..e      characttr  isi  re 
rriiTiaiii\    suited    to    tie      reusability    concept.         Aithcu.jh    t.-.< 
software    developed    by      these    two    groups   consists       ii:-:  L_    or. 
numerical    subroutine,      this    dees    not    exclude    the    feasibility 
cr    using    their    concerts    en       ether    iJres    o:    software    :rceucto 
(i.e.,    r.cn-r. umerical). 

Ir  discussing  tne  inraru.es  developed  by  I.iSL  anc  ;-,:AG, 
the  author  is  net  implying  tnat  the  characteristics  repre- 
sented by  each  is  better  or  kcrst  than  any  other.  But  tne 
objectives  cf  the  twe  libraries  are  close  to  those  dtiiica 
in  the  conceptual  Program  library.  Ihe  characteristics  cr 
lack  or  will  be  discussed  for  both  tne  I  MSI  and  .»AJ 
libraries  and  hopefully,  the  concept  or  tne  Program  library 
will    teccne    evident    tc    the    user. 


E.       TEE    2MSI   LIBRARY 

The    IMSI   library    consists    of    over    400    high    quality    nath- 
ematical      and    statistical      subroutines.         These      subrcutires 
represent      programs      derived      from        a      variety      of      sources 
(including    cnes    written   by    IMSI)  .         Regardless   of    the    scuicc. 
,    all    pic  grams    are    rewritten    with   a    .uniform    (i.e.,    standard) 
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style,      according   to    rice  [Bef.    7*],    *uaiit/    control    is    exer- 
cise d    by  : 


(a)  choosing  good  sources  (the  advisors,  a  beard  oi 
12-15    experts,    assist    in    this    regard) 

(b)  usirg  kno  wledgearle  programmers  with  goou  supervi- 
sion (some  of  the  senior  I^SL  reopie  work  regular^ 
en    the  library    programs) 

(c)  testing  (reasonably  exnaustive  ror  »iew  pro.grairs, 
check  _-.oi.nt  testing  for  maintenance  or  new  machine 
versichs] 

(d)  ccrtitual    upgrading 


As  ;.icrcsed  in  [Bef.  11  ]/  the  IMS1  library  has  moved  to 
a  Tortrar.  converter  system  where  a  master  frit;  contains  ail. 
the  inrcimation  needed  for  eaci.  machine  version  or  a 
prograiL.  Much  or  the  standard  information  is  not  exp^iciti^ 
in  the  file.  A  converter  program  then  automatically 
produces  the  program  ror  a  particular  target  machine.  Ihe 
master  rile  is  itself  a  Fortran  rrogram  that  runs  or.  one  or 
the  machines.  Thus  portability  is  an  attribute  oi  the  I*5L 
libr  ary . 

The  characteristics  of  the  IdSL  iirrary  subroutines  and 
documentation  are  of  major  concern  to  a  user.  Aside  from 
the  standardization  of  tne  documentation,  there  should  be  a 
good  understanding  of  the  general  attributes  residing  in  the 
library.   The  attributes  [Ref.  12]  are  as  follows; 

(a)  Testing  of  the  library  subroutines  were  performed  at 
several  levels  in  various  computer/compiler  environ- 
ments . 

(b)  for  each  routine  which  has  some  error  detecting 
capabilities,  the  user  is  protected  ny  default.  That 
is  if  the  user  chooses  to  ignore  error  possibilities 
a  warning,  in  the  form  of  a  printed  message,  is 
issue  d. 

(c)  iach  routine  conforms  to  established  conventions  n 
coding  and  doc unentat ion. 

(d)  rach  routine  was  designed  and  documented  to  ce  used 
ty  technical  personnel  in  fields  of  science,  engi- 
neering, medicine,  agriculture,  .  .  .  ,  and  in  re- 
search activities. 

(e)  Accuracy  of  results,  clarity  of  documentation.  and 
efficiency  of  coding  were  given  first  Driority  in 
development. 

(f)  Periodicals   and   books   are   referenced   for   users 
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anc    ^lo^raniners     (or    Idol    per  so: 
a      ccac)       are      available      to 


J-    C  w    I.    w  . 


lie    general    attrilutes      as    mentioned    are    not      ail    ir. elu- 
sive,     tut    are      enough    to    provide    sj^c      ande ^standing    zl,    it. 
capacity    or    the    library.         Io    reinforce    tne    integrity     z  :.    ;:-: 
linrary,    IK Si,       as    tit    sole    source    of    any    technical    ir.roria- 
tion    regarding    tLese    icutmes,      assumes    total    re  sponsion  it_. 


th 


operation 


c  i    an  ■ 


i  c  a  t  in  e . 


±0 


;ac  imitate 


retrieval  cf  the  various  routines  and  their  associated  ioou- 
rentation,  IHSL  has  established  a  directory  of  rcucir.es  in 
which  each  routine  has  beec  placed  in  an  alphabetized 
categcr^.  IMSI  aisc  provide  a  key-word-in-context  (KWIC; 
listirg  which  offers  the  user  a  guick  reference  co  a  routine 
giver  th€  user  has  knowledge  of  the  title.  This  is  not 
always  oeneficial  since  there  are  many  cases  where  the  title 
does  net  accurately  reflect  tne  contents  of  tne  routine. 
However,  tne  concept  of  a  key  word  retrieval  aechanisn,  aust 
not    te    oterlooked. 

Although  the  IMSI  library  has  the  aany  characteristics 
mentioned  above,  the  retrieval  and  uianipula tion  of  the 
routines  is  ^enerallv  hidden  from  the  user.  Should  tne  user 
desire  access  to  the  IMSL  Library,  the  capability  does  exist 
and  the  routines  can  be  incorporated  into  the  user's 
prograa.  Ihere  are  proriems  encountered  whe n  attempting  to 
interleave    a   user's    program    with    'the    IMSI    Library;       usually 
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these    j  r  c  z  1  e  ms    are       r  c  r  e    e  v  i  j  e . 


m    tne 


'oauctici    environ- 


ment   than    in   an    institutional      organization. 


iiitc    reason    is 


tie    increased   productivity    expected   b; 


ni  os  t 


rod  uc  t  a 


or  ;a- 


nizatiens. 


me 


12  £ I    Librar 


Can 


used    as      a    guide 


conceptualize   a    functional    Ercgram      Library    with    scae    exten- 
sions   to    its   existinc   characteristics. 


C.        1EZ    HAG    LIBRARY 


lie  UAG  Library  represents  a  high  e'jality  r.ux 
aigorithn  library  for  general  use  by  universities,  I  •: 
by  design,  represents  a  porta  tie  system.  The  in  AG  1 
[Rez.     15*    operates    as    follows: 
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The  NAG  uses  a  master  library  fixe  system  (similar  to 
the  1HSL  master  file)  which  contains  all  versions  of  £ac~> 
program.  It  also  keeps  a  complete  history  of  the  versions 
cf  each  program.  Eue  to  the  nigh  level  language  (i.e., 
subsets  cf  Fortran,  Axgol  60  and  Algol  68)  and  machine 
parameterization ,  new  machine  implementations  are  essen- 
tially automatic  (i.e.,  transparent  co  the  user)  .  -Jhen  an 
imple mentation  is  accepted,  the  programs  are  returned  tc  the 
NAG   Central  Office   for ^inclusion   in   the  master   library. 


2  1 


1  X  Li  X  'i  i.    ■        i.Cij\  il.^ 

to  assure  equivalent  ttif oriaice  of  the  HAG  Library  versions 
[Hex.  1^1-  According  to  ^Bef.  15],  the  iixrary  .uiicr; 
irl  ox  n  a  tier,  and  test  ^.ro^raas  in  the  master  file  have  Leen 
found    usefux  in    developing    a    mere    ^oxta^^e    iiixaxy. 

lie  NAG  Libxaxy,  in  a  similax  marnex  to  cnat  of  tic  lliSL 
library,  provides  a  working  understanding  or  a  sufcrcutir  = 
library.  Sith  the  concept  of  the  Li  AG  Lixxaxy  l  =m=  jst:  a.: 
a  -j  uict ,  t  r .  e  t  a  s  k  01  estabiisning  a  ^xo-jrax  -i.^  Lar  ^  5  1.  o  u  a  1 
icec    citainacie. 


E.        CSIBVII*    OF     CHAHAC1ZRIS1IC2 

Kliie  the  Iiv:SL  ana  NAG  libraries  appear  co  set  ::.  ^ 
c ui J e li n e s  x ox  an  eficctive  ?x  c  ^  r  am  L 1  x  x  a  x  \  ,  z e i t l. e  r  ".as  t. -. 
characteristics  expected  of  a  functionally  reusable  Pxcgrii 
library    as      proposed    ty      this    thesis.  Specifically,      _ct.. 

libxaxies  have  beneficial  characteristics,  oat  each  neglects 
the  issues  of  xeusaiility  (e.g./  cataloging,  key-.cri 
indexirg    and   xetxieval,    etc.). 

lie  chaxac texist ics  ox  the  IMS!  and  ft  AG  Lxbxaxies  which 
support  the  concept  cf  the  Program  Library  -wiii  be  discussed 
and  presented  as  feasible  qualities  to  be  associated  witn  a 
good  library.  lo  broaden  the  perspective  ox  a  lxtxaxy,  tne 
characteristics  and  attributes  of  tae  IdSL  and  the  SAG 
libraries  should  be  slightly  modified  and  in  scae  cases 
chanced    to    fit    new    jcals. 

A  clcsex  look  at  the  two  libxaxies  xeveal  the  following 
goals    ici    a    possible    fxogxan    Library: 

(1)  lie  design  and  implementation  of  the  Program  Lirraxy 
should  be  under  the  auspices  of  a  group  of'  experts 
from  a  wide  xaige  of  sources  '  (1. e. ,  designers,  pro- 
grams ers,    etc.). 

5  2 


(2) 

(«) 

(5) 

tc) 

{1) 


re  identified  and  the  library  must  sufro 


di}'  latter  tradeoffs  will   ce   on 


(8) 


(5) 


(10) 


Ire  environment  of  tee  Program  Library  i^t  r«; 
established  sr.d  all  testing  must  be  accoipl ish 3d 
within   it. 

lacn  entity  within  the  library  should  re  coreic^rei 
fcr  error  detection.  requirements,  i^.ro-riatc  error 
nardling  capafiiities  must  re  outlined. 
5  tan  car dizaticn  or  coding  ana  documentation  is  3  an  ea- 
tery, for  ail  entities  within  the  library  or  evolved 
ficni  the  library. 
The    clientele    cr    users    cf    the    PrcgraT    Li.crary       ;::-.' 

them. 
Ire    deve lc^ me rtai    criorities    s:ouxi    ts   sec,       =  c      t..i: 

m  in  c  r       i  e  t  a  r  1  s       2  z 
ci^-csec    tc    major    is  sues. 

Ire  deveiepmert  of  the  entities  witnm  tne  library  is 
urgortant  and  although  the  actuaj.  specifics  car  net 
re  placed  in  tie  library,  references  providing  Know- 
ledge of  the  details  should  be  made  accessible  tc  t..-- 
user. 

The  library  sbculd  represent  a  user -friendly  tic;j;:. 
Thus  wnen  manipulating  entities  in  the  library  there 
should  be  apprcpnate  tests  for  applicability  tc  the 
user's  reguirenents,  thertoy  making  it  possible  to 
guickiy  identify  and  avcid  some  of  the  prcciems  of 
parameter izaticn. 

lie  library  is  to  be  its  own  best  source  of  informat- 
ion. Any  inquiries  as  to  the  use  of  the  library  will 
be  answered  by  its  own  documentation,  alleviating 
the  need  for  exterior  (i.e., Looks)  information.  Ibis 
inclies  or- line  access  to  both  the  documentation  and 
tie  ether  entities  as  they  are  used  in  the  library, 
fcr  the  new  user  of  the  iinrary,  tnere  should  re 
example  inputs,  results  and  formatting  restrictions 
and    guidelines. 


Jj 


(11)  lie  organization  responsible   for  the  con 


t.ic 


S  u  j -jested      additional 


Program  Library  and  its  design  and  implementation 
should  also  be  responsible  to  tne  users  for  continued 
updating    and    aaintenance. 

The  aforementioned  characteristics  will  rrovide  a  good 
yuaiity  library  but  what  is  lacking  is  the  characteristics 
that  will  make  the  library  reusable  to  tne  user  arc  his  cr 
her  organization. 
should    iiclude    but    net    be   limited    10: 

(1)  The  ability  tc  select  the  most  optimal  entities,  :o: 
the    accoij-j.ish.ient    01    the    user's    task. 

(2)  Library  browsing  capability,  prior  co  the  iticctic;. 
of    a    comrcnent    within. 

{3)  lie  ability  tc  locate  a  component  j:  a  similar  com- 
ponent with  the  use  cr  key -words,  indexing  and  cica- 
lcging. 

(4)  :i articulation  ar.d  retrieval  capabilities  on  entitle^ 
cr.ee    located. 

(5)  lie  ability  tc  modify  and  comnine  authorised  modules 
sc  as  to  possibly  create  larger  modules  in  a  hier- 
archical manner.  This  sneu^d  be  accomplished  while 
keeping  the  parameter  passing  process  transparent  to 
the    u  se  r . 


As  a  final  comnent  on  the  IMSL  and  HAG  Libraries, 
certain  observations  _seem  evident.  One  is  that,  as  ni-,h  a 
guality  as  the  two  libraries  appear  to  be,  there  seens  tc  be 
little  tc  indicate  that  the  issue  of  reusability  is  of  any 
concern.  This  thesis  uoes  not  deny  that  a  gocd  library 
could  very  easily  be  created  from  the  linage  of  either  the 
IMSL    cr    the    NAG' library,    however    it    could    re    said,       that    the 
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ro3iai   Litrary  is 


Superset"   (coLtiiii;.  3  the   ccnar.c 


CLdidctiiistics)  of  tne  twc  -i..i..crarie  s.  Ihe  aa.iL  intent  is 
to  rrcvide  characteristics  icr  a  reusable  Program  iiciary, 
with  th€  belief  that  reusability  produces  increased 
pro  duct  lvity- 


^  c 


IV.  1HE  PiCGBA^  LI33ARI 

Ihe  trcgram  Library  represents  a  conceptual 
res^crsive  to  the  widest  range  of  users  (irsm  the  ncvics  to 
the  exrert)  .  The  litrary  is  to  :c  established  arcana  ^a.s 
consistert  with  user's  needs.  To  understand  the  conceptual 
design  and  i mole  men t a tion/  the  goals  or  tne  Jro::ai  Library 
wi.il    ie    idertined    arc   explained. 


A.        GCAI2    Cr    A    PEOGBM    1I32A5Y 

Initially,  the  Ercgraa  Litrary  should  be  ^si,:^  ;j  1: 
to  b€  cr  benefit  to  a  wide;  range  or  users.  Included  m  i  ;;j.a 
design  sr.cuid  he  considerations  for  reliability,  mccir-- 
ahility,    under st anda tility,     testability    and    efficiency. 

An  ether  3oai  is  to  have  a  library  that  nas  pew  err u a. 
capabilities  and  has  the  flexibility  to  ce  easily  jioairre: 
to    fit    srecific    user    needs.  with    tn=    design    being    centered 

en  these  issues,  the  potential  to  create  useful  iirraries 
can      be    enhanced.  This   issue      will    be      discussed    in      sere 

detail    ir    the    followirg    sections. 


Another  goal  is  tc  eiapnasize  portability.  Portability 
should  stress  the  ninimiza ticn  of  change  as  a  software 
product  is  moved  frca  one  environment  to  another.  Thus, 
portability  in  the  Picgram  library  will  require  moving  free 
cne    envncnaent    to    a  nether,  causing    concerns   over    compati- 

bility   and    parameter    passing    issues.         Ih=se    are    seme    ci    tho 
issues    that      should    t€      deait    with      by    the      designer    of       the 
product    and    recognized  •  by    tne    user.         Ihe      concepc    ci    port- 
ability   as      a    goal       icr    the    Prcgraia      Library    changes      as    tne' 
type    cf    environment    varies.  That   is,    tne    concerns    invclved 
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in    uoviuvj    tetweec    tvc    unrelated    con^u  tei .  cnVj.ron.uen  ti     (i.e, 
IS  a    36C/37Q    and    Cyber   205)  are    scrarate    iro.n 


o  o  t      t  ..  •_ 


^  C    C  J. 


tciea  ir  iicving  between  environments  located  within  a  larger 
envir cnment  (e.g.,  tie  UNIX  and  VMS  operating  systems  within 
tne    VAX    ccicputer    syst€ff). 

rinally  and  aost  importantly,  the  laiue  of  reusability 
irust  he  addressea  aid  tne  concept  incorporated  intc  t..i« 
lihrary  iirca  the  design  stage  to  tne  Jieii  ijj-" 
The  reusability  issue  snould  he  a  nasis  her  tn 
imp le Hen tat ion  and  use  of  the  tro^ram  Library.  1 
behind  reusability  should  net  he  limited  co  the  z^~~-}.. 
phase,  since  the  extension  of  the  concept  dewr  to  cne  ::_: 
primitive  entities  ir  the  library  will  aj.so  enhar.Co  t.:-; 
user's  rio^iaaai^3  task.  Most  users  of  a  software  b.rca-ct 
are  interested  in  incieased  savings  (in  time  and  money)  an; 
increased    productivity      in    programming.  Reusamlitj     is      a 

suggested  path  tc  these  joals,  and  if  tne  Program  Library 
and  its  associated  entities  are  to  reach  tne  desired  c,cdis, 
the    ccrcept    of    reusability    must    be   implemented. 

I  he  coals  cited  above  for  the  Program  Library  are  Ly  uo 
aeans  conclusive.  They  merely  rrovide  a  conceptual  overview 
cf  what  a  user  should  expect  from  an  operational  Frc^ram 
library. 


E.       A    EIEBAECHICAL    HITS    OF    THE    PROGRAM    LIBRARY 

Ihe  Ero^ram  library  can  be  described  in  a  nierarchicai 
fasnicr.  The  hierarchy  of  tne  Program  Library  consists  of 
entities  embedded  in  aultiple  conceptual  layers,  each  layer 
representing      a    library.  An    example      of    a      aierarcnicaiiy 

layered      model    of      the      Program      Library    is      represented      in 
figure      4.1.        The       layers    of      the      library    represent      three 
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conceptual    levels      which    make-up      the    ?rc3'i*aa      .--:i.:  . 
tr.is    three    level    exaiple,    chc    I=vCj.s    die    ciaiiii-tcu    as    a 
level    Lirrary     (111),      a    'Aid.    Ltvei      Li^raij     O'ili)        ana    a    . 
level    Lirrary     (Hllj  .  Zach    level    can    then      ce    descrire; 

how    its    associated    rcutines      aie    iiani.cuu.ated     (i.e.,       re- 
riodiii*  d  ,    e  tc. )  . 


1  . 


i  :.  e 


lo  w    Leve 1    Lirra  cv 


k  routine  or  any  entity  at  t.~. e  *jv 
writtei  in  source  cede.  It  is  a  stan a- alone 
loucint  which  calls  nc  other  loutine. 
routine^  at  t.r. is  j.  e  v  1 1  a  r  i  no*  exclusive  zo  an 
ci  package  at  a  nignei  icVel.  In  iact,  saca  i 
higher  j.eve^  has  access  to  each  and  every  rouci 
i^vel  .  This  does  net  rrecluie  the  auiiity  to 
routines  cr  manipulate  them  as  reusable  soft«ar 
is  a  implicit  linitaticn  on  the  s^ne  (i.e.,  r.u 
cl    cede)       ex      the   routines    at    this    icvei.         At 


ent 


e  v  •=  j. 


routine  should  Le  ex  tec ted  to 


die  oni;  one 


giving  validity  to  the  term  "single  action  ion 


J  U  1 1 he 

n e  at 

LU  O  Jk  J*.   -J- 

a:  o  e  r  c 
this  . 

a  c  1 1  c  i~. 

■ .  -.  -     ii 


2  •   iie  Hid  level  library 

' lach  entity  at  this  level  is  constructed  ci  source 
language  cede  derived  from  the  linking  (via  sutrcucine 
calls)  tc  lower  level  routines.  Thus,  tu-a  lower  levels  can 
he  viewed  as  providing  operations  not  available  in  existing 
(i.e.,  .'lid  level)  cede.  At  this  level  the  size  or  the  enti- 
ties is  or  major  importance  to  the  capatxiity  ci.  the 
lilrary.  Ihis  is  evident  in  the  fact  that,  even  thcugh  the 
size  ci  entities  at  this  level  is  comparable  (cot  neces- 
sarily larger)  to  tie  size  or  entities  at  the* lower  level, 
they  are  acre   capable  because  of  the   availability  cf  calls 
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Figure  4.  1    Hierarchy  of  the  Program  Library 
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to    ic*ti    iiVc-3.         Jricr  filiate]  ~2 ,    at    u,is    an!    fi.ijr.er    xtv-i;, 
'he    capability    of    the      library    i^rcovcs,       tne    flexibility 
This    is    the   f unda mental    tiia-jci:    retveei.    levels   of 


a.a 


'  L       Ci      ^ 


a   Prcciaii    library;    tie    increased   rower    ci    higher    xcvei    enti- 
ties   is    available      oily    by    decreasing    flexibility. 


-  •      Ik^    High   level    Ii.or an l 

1h e    avera3e    user,       net    wanting    to    *aste    t. 
a      fic^iaa      from      scratch,         seeKs      code      rerrese 
c~*arlete      components       (i.e.,         application      r  a.z.\d 

Set  1 1  S  I  J      thiS         ic  jUta  t      tiit     ?  I  'J  3  I  i  £         Ll  Jt  al  V      ,"id;      - 

library  accessible   tj  tn*=  user.     As  witr.  me 
libraries,  its  ccnteits  are  still  ess^-t^ali^.  no 


reusable 


The  size   oh  tae  amplication  packa- 


fcS 


fully  siall  (relative  to  packages  con srruc teu  fro 
libraries),  out  have  significant  capability. 
rcses  the  issue  cr  a  txadeeff  between  ca_ar..j.i^.t  / 
hiiitv  kith  the  user  being  the  beneficiary  or 
res  ul  t . 


are  z.  c  -  < 

n    u  r-  1  a  j  •=  r « 

i  h  i  s  a  -,  a . 


a .. ..  a. 
the 


C.   AIVASTAGES  OF  A  HIERARCHICAL  fBOGHAM  LISHAEY 

In  the  structure  shown  in  figure  4.2,  if  a  entity  at  t.ie 
hignest  level  (level  2)  wants  to  make  use  of  a  entity  at  the 
lowest  level  (level  1),  the  calling  sequence  must  aake  use 
cf  the  entities  at  tie  mid  level  (kve^  2)  .  And  srculc  the 
routine  lateled  B  wish  to  use  the  routine  larelc:d  G,  it  must 
pass  through  the  routines  lane led  A  and  C,  since  the;/  are  in 
the  hierarchical  calling  sequence.  This  type  design  is 
similar  tc  the  designs  that  use  the  concept  of  ster«iss 
refinement.  Therefore  the  flexibility  available  to  the  user 
is  .United. 
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EVE 


VEI    2 


figure   4.2 


A    Hierarchical    Structure. 


I  he  Erc^ram  library's  structure  as  snown  in  Figure  4.3,. 
cifers  nest  of  the  relations  sought  in  Figure  4.2,  rut  ih& 
unigu€    distinguishing      feature    is      the   potential      tc    deviate 


iron    the    Hernial    calling    sequence 


hat  is, 


tr.< 


associated  with  stepwise  refinement  in  a  hierarchical  struc- 
ture are  still  rsievait  with  this  design.  Though  new,  the 
user  has  the  ability  tc  perform  manipulations  (i.e.,  cails 
to  routines)  from  high  levels  to  low  levels  without  passing 
through  the  middle  levels.  For  an  example,  routine  A  at 
level  3  can  make  use  cf  routines  B,  2,  F,  or  G  at  level  1. 
Another  example,  illustrated  in  tne  rigure,  provides  tii« 
anility  fcr  two  or  mere  routines  at  the  same  level  (e.g.,  3 
and  C  cf  level  2)  to  make  use  of  any  routine  at  level  1 
(e.g.,  E,  £,  F  and  G).  A  mere  indepth  explanation  cf  this 
and  the  previous  mentioned  relation  can  be  fcuca  in  the 
article  ry  Earnas  [Ref.  9]  en  the  "uses"  relation. 

Even  thcugh  the  fiograms  in  the  'multiple  xevel'  Program 
library  may  be  identical  tc  those  in  a  single  level  design 
'(similar  tc  that  of  the  IMS  I  Lilraryj  ,  giving  the  user  guick 


4  1 


LEVEL    2 


LEVEL     1 


Figure    4.3        Hierarchical    Structure    of    a    Program    Library. 

access  tc  tr.e  prcgrans  at  the  lower  icveis  will  allow  him  or 
her  tc  use  the  library  mere  effectively.  Kith  the  hierarch- 
ical cesign,  the  usei  now  nas  a  large  selection  of  routines 
for  writing  programs  cr  nigh  level  applications.  Ii  tr.er^ 
is  a  need  tc  modify  a  high  level  rrogram,  the  user  only  n€ed 
to  optiaize  the  calling  seguecce,  since  tae  programs  are 
writter  in  terms  of  calls  to  lower  level  programs.  Since 
the  prcgianner  can  acdify  the  program,  he  or  sne  nas  the 
anility  to  add  or  delete  the  capability.  Also  with  the  use 
cf  calls  tc  lower  level  programs  the  size  of  the  higher 
level  programs  are  ret  nearly  as  large  as  tnose  used  in 
different'  designs.  Finally,      the      hierarcnical    desi-jE      is 

consisteit  with  the  state- cf-the-art  technology,  known  as 
"mod  ularity .  " 

1  *      JL2  "..§:£   §^  J    Fie  jilili  t  y    in    a    Program    Litr  ar  y 

Eotn  power  aid  flexibility  of  a  Software  frcauct 
regin  ir^  the  design  phase  or  its  life-cycle  and  both  afreet 
the    user's    programming    efficiency.  The    granularity     (i.e., 
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size)     cz    tie   ?ro3ram    library    siculu.    r^resiL:    a    najcr    lCjis- 


dient    in    the    library's   rid    for    power   and    iie.iinj.iit 


an 


attempt  tc  rrovide  bcth  conceptual  jOdiS^  while  k££ti£5  tne 
granularity  of  the  library's  entities  as  small  as  .cssirie, 
any  and  ail  tradeoffs  should  he  examined.  One  anticipated 
example  cf  a  tradeoff  is  due  to  the  issues  around  entity 
size.  That  is ,  in  crder  to  maintain  the  size  of  entities,  a 
hierarchical  approach  tc  program  creation  and  modification 
should  he  used.  As  the  entities  are  raised  :o  a  hijr.ee 
level  in  the  hierarchy,  the  acre  capable  the  lib 
heccie,  whil  e  the  decree  cf  ilexii.il  ity  is 
Although,  the  two  cencepts  are  equally  important  tc  :ae 
design  and  eventual  inclement ation  of  the  library,  there 
will  re  instances  where  one  will  oe  prefered  to  the  ct:.-.:. 
Ihe  designer  and  user  cf  the  Program  Liirary  should,  at  ai^ 
times,  seek  an  ecuitable  balance  between  pevs:  and 
iiexi iiiity . 


*  *.  -»  -. 


c  o  i  c    .  = 


rrcn.   the 


nr cs^ecti ve    cr 


the    US' 


_  v-  -i  LCL 


library,  programmers  of.  any  level  of  proficiency  will  be 
able  tc  write  applications  easily.  The  novice  should  r  = 
able  tc  inclement  entire  applications  with  a  minimuir  cumber 
cf  calls  tc  lower  level  routines.  A  more  experienced 
programmer  should  be  able  to  generate  a  jreater  recertcire 
cf  routines  for  establishing  applications. 
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V.     THE    AEDITTCN    CF     AN    APPLICATION    GSNZSA2C.fi 

The  prcc,ram  Library  has  tte^  described  as  a  Software 
Product  designed  as  a  hier archical  structure  oi  libraries. 
The      concept   provides      tne    designer      and    tne      user    a      hig«iy 


effective 


and    reusa;.! 


sort*  a r  e 


tOJi. 


_ve; 


he  j 


Pro-,rai    library    suggests    to    the    user    a    new    and    "easy"    .; 


I  r  o  g  r  a  m  i  i  ; 
as  =:-:  ^  t  o  t  = 


for  tie  nrrrovement  tc  program  proauctivit 
recuires  that  the  user  have  scue  formal  pro.j 
edge.  Thus,  it  is  net  as  "  user-iritnu.^  " 
product  raeei  on  a  hi  jr.  level  language.  A  r.i  ..  _-.  ve. 
programming  language  that  ccuic  he  jSci  to  ~  a  ■■  ^  ;■  .-..-. 
succinctly  express  troblems  wcula  be  a  very  vaiuatle  tool 
ror  iiprcving  ^r cgran a er  productivity.  One  approacn  tc  this 
has  teen  tc  investigate  "Automatic  ?r  ograiuming "  systems. 
Zaizer  [Bef.  16  J,  jives  an  example  of  a  system,  that  wcild, 
for  any  prcblem,  au  tcmatic  ally  construct  a  working  program 
from  a  description  in  a  very  high  level  language.  Inis  wcrx 
has  net  yet  produced  a  practical  system  that  is  easy  nor 
non- p rogrammer s  to  use;  the  difficulties  in  resolvir.3  ambi- 
guities and  inccnsistencj.es  m  the  problem  statement  o^e^ 
intractable,  in  at  least  the  near  future.  A  sec end 
approach,  that  is  practical,  is  to  work.  within  a  limited 
problem  domain  where  the  problem  is  well  defined  and  tr.er^ 
is  an  available  notation  tc  resolve  any  amoicuities  cr 
inconsistences.  These  systems  are  ca^i  program  generators. 
As  an  example,  the  program  synthesizer  used  by  many  indus- 
trial ccipciations  gives  the  capability  to  generate  any  ci  a 
whole  class  of  similar  programs  and  tne  user  needs  enly  to 
input  special  information  related  to  his  particular  applica- 
tion. _  Cn  the  basis  of  this  input,  the  system  outputs 
reasonably   standard   code   adapted   appropriately   fcr   the 
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user  '  s   task. 

generators  ior   industrial  ap plications  such   as  scheduling, 

invertcrj  management ,  cr  payroll. 

Tc  put  the  user  in  a  position  where  he  or  she  r.  eec  ro- 
le experienced  programmers ,  the  designer  or  a  hign  level 
language  should  further  simplify  the  so  called  "hign  level 
language"  (e.g.,  FC51BAN)  .  One  method  of  siiciiijii;  <» 
PCHCFSN  like  language  is  by  the  coiia^sin^  of  several  lir.es 
cf  ccnircr.  patterns,  such  as  tne  LG-Ijc^  or  FCF.-lco£,  into 
just  cue  cr  two  symbols.  The  language  API  lv  Iversic:. 
(1972)  [Fef.  17],  gives  an  example  of  now  tnis  car.  :s  zone, 
while  the  level  of  the  API  language  nay  not  egress  '..,-. 
lev~l  to  which  tne  ±.  retrain  generator  is  proposed,  it  :cej 
give  a  conceptual  via  of  what  is  expected  of  tne  -,e  r.e  r  2t  cr  . 

Ir  accordance  with  tne  hierarchical  model  proposed  zor 
the  Frcgzam  Library,  the  program  generator  should  also  he 
represented  as  a  level  or  the  hierarchy.  Tne  level  shcuii 
re  referred  to  as  the  application  generator  as  shew:,  in, 
figure  5.1.  As  with  the  Program  Library,  it  should  include 
varices  program  generators  consistent  with  tne  organizations 
overall  coals  (i.e.,  business,  statistical  anaLysis,  etc.) 
Tne  prccram  ^eneratcrs  shcaid  respond  to  the  Application 
Genera  icr's  environmert  in  a  similar  fashion  to  the  way  the 
libraries  respond  within  the  Program  Library's  environment. 
Therefore  the  progran  generator  can  be  modified,  and  reused 
in  a  manner  similar  to  that  cf  a  routine.  As  the  figure 
implies  the  Inventory  Management  element  cf  the  application 
generator,  being  a  prcgram  generator  itself,  must  be  viewed 
as  being  on  the  sane  level  as  all  the  ether  generators. 
Thus,  each  must  be  capable  cf  communicating  down  -  to  the 
varicus  levels  of  the  Program  Library.  An  important 
restriction  on  the  prcgram  generator  is  that  its  components 
are  net  permitted   tc  communicate  directly  with   each  ctner. 


U5 


APPLICATION    322IZr.AI< 


■  — 

1 

Program 
Gene  ratoi 

i 

Gener  ator 

J 

Inv  enter y 
Management 

PEOG3A3 

L 1 3  t  A  r  i 

figure    5.1 


Hierarchical    Structure    with    Additional 
application    generator. 


Kith  the  very  high  level  application  jencratci  the  hierarch- 
ical structure,  previously  presented,  remains  valid  and  now 
the    user    has   a    mere    user-friendly    system. 

A  clcser  look  at  the  application  generator  will  illus- 
trate one  method  of  writing  siiilar  programs.  The  netnci  is 
to  segment  the  required  task  into  two  parts,  rcut-ine 
portions  that  are  ecu men  tc  all  programs  at  that  level  and 
task-dependent  portions  that  must  be  different  nor  each  new 
pro-,ram.  I  he  progran  generator  will,  respond  as  a  program, 
that  automatically  executes  the  more  routine  portions  ci  the 
program    task   and    enahles    the      user   conveniently    to    input    the 
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task-dependent    iifcr  act. 


so  that  1 1. e  :c£i:t 


i  u  Ca^ 


re  created.   More  detailed  discussions  or.  hew  this  is  accom- 
plished car  be  fcund  in  [5ef.  13]. 

The  siaplici ty  of  this   software  product  tecoa^s    evident 


wnen    tee 


enerator    acts   as      an    automatic      program    jtLeiato: 


for  applications  specific  tc  a  wording  environment.  Ine 
Prograa  Generator's  efforts  are  aimed  at  giving  the  ^ce: 
Kith  nc  traditional  programming  expertise  the  anility  t; 
generate  useful  programs  while  working  with  familial  ter~s. 
lie  Eu  sir  ess  Definition  Language  (31 L)  system  heir-  devel- 
oped at  IBM  (Goldberg,  1975);  Hammer  et  ai,  197^  z:.  : 
PB01C5YS1EM    I     (Marti  13    et    al .  ,       1974)       at    .ill    ;r=    exaapicS    : . 

user's    ervircriert 
[Ref.    19*,    [Eef.    20]    and   [Eef.    21]   respectively. 


an    autc'atic      ^rcgraa    generator      ror    tn 


I  c    rrcvide    a      working   exaiple    of    tne      program    5erera' 
as      it    xiteracts      with      the    user      and      the    Program 


ii.ii.ai, 


Pigure 


I  he 


figure    illustrates 


cnart  created  by  the  user  within  an  interactive  grapnics 
program  package.  It  also  illustrates  the  interface  between 
the  generator  and  the  Prograa,  Library.  This  interface  is 
transparent  to  the  inexperienced  user  nut  tiie  experienced 
user  is  allowed  a.cc€ss  whenever  he  or  she  desires.  Ihe 
diagrams  as  shown  describe  the  program  as  it  is  izeirg 
created;  they  could  also  be  thcu^nt  of  as  the  ^ro^iai  or  ac 
least  part  of  it.  £mce  this  generator  can  ce  described  in 
terms  of  another  such  flow  chart,  then  iron  a  conceptual 
standpoint,  more  thar  one  generator  may  be  permitted  m  the 
application  generator  at  the  higher  revel.  The  ^eneratcr  at 
tnis  pcirt  is  still  consistent  with  the  hierarchical  struc- 
ture representing  the  Program  Library  and  the  environment 
surrounding  it.  The  specific  design  of  the  prograa  gener- 
ator is  to  aake  the  user's  task  as  simple  as  possible.  Kith 
this  ir  mind,  the  following  process,  in  .figure  5.2,  is 
outline  d . 
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figure  5.2    Example  of  a  Program  Generator, 

Giver  a  programmer  concerned  with  processing  cruers,  he 
must  first  make  his  objective  ciear  to  the  interactive 
program  package,  presumably  being  used  as  the  peripheral 
device.  Incidental  to  the  processing  of  orders,  a  chec*  cf 
the  program  file  is  nade.  This  is  to  verify  the  existence 
cf  the  reguired  program.,  hut  not  naxt  the  rrocess  ir  the 
progran  is  rot  presert.  Once  the  objective  nas  re  en  •identi- 
fied, the  specific  process  of  interest  to  the  user  is 
invoked  ty  the  Progran  Specification  Language  (?SL) .  Ihe 
irecharics  cf  the  above  operaticn  is  automatic  in  nature  and 
transparent  to  the  user.  But,  should  ti.e  user  reguire  a 
iiore  optimal  soluticr,  he  or  she  nas  the  capability  of 
manipulating  appropriate  application  packages  or  routines 
within  the  Program  library.  The  interface  between  the 
Program   Gereratcr  aid   the   Program   Library  must   be   well 
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Ihe    significance      or    tins      rroiuct    is      to    introduce      the 
roticn    of      simplicity    and   of    reusability.  By    i  e  p  ie  renting 

user-friendly       (high-level)  languages    with      special       (task 

crier.ted)  operators  and  forns  designed  ror  ,ar;icuia:  tvres 
cr  computation,  repetitious  ccdin3  or  programs  ray  re  c„u- 
rated.  These  nigher  level  languages  ar<=  meant  tc  includ-i 
constructs  tnat  are  adapted  rcr  particuicir  applications  and 
t..  at  are  natural  fcr  conceptualizations  in  tr.e  r[c:it_ 
domair.  ficpefuily,  such  languages  will  allow  the  programs 
to    re    concise   and    efficient.  Since    tae    generator    cc=rated 

somewtat      automatically,         the      user's      anility      tc      prcduc*= 


correct 


imprc ved 


ana 


reliaile 


-r  c 


3*; 


ii.oai 


coasiatraii, 


Ihis    insures    increased   program    productivity 


Examples  of  Program  Generators  and  PrCjiaa  Libraries  ar- 
in  existence  and  marketable  today,  tut  as  far  as  it  cah  be 
detenined,  there  is  not  a  software  product  ol  the  larket 
that  provides  a  combined  environment,  as  exhibited  arcve. 
Ihis  is  net  to  imply  that  similar  products  do  not  exist.  As 
an  example  of  one  crganiz aticn ' s  errorts  at  bringing  the 
concepts  cf  the  generator  and  tne  library  together,  the 
relieving    is   worth    mentioning. 

lie        I  iter  national  Mathematical        and  Statistical 

libraries,    Inc.      (IMS!)    known    for    its    numerical   computational 
library,    designed    a    system    for    a    user    so    that: 


his    programming    effort    cculd    be    reduced; 

he    could    have    improved    errcr    control; 

he    cculd    have    a   system    which    is    designed   for    ease    or 

use«_    with. the    intent    of      increasing       problem-solving 

a      single      computer 


productivity;    and 
(d)     ne    wculd    net    be      restricted      to 


envircnmen  t. 


IMSL's    sciutior    to       assisting    the    user    is      called    "PECIIAh,11 
{for    rrCcran    lEAN'slatcx)    cHer.    22],         PEOIRAN    ia    designed    as 


a    zaniiV    c 


:oft>are    jroduc  ts, 


L alxl     dTCUHu     d 


s  p  tec ts;or 


that    crcduces   FORTRAN   code    which    perforins    the   actions    sreci 


iied    ty    the    user's    PrCIEAN       statements. 


The  FOR  IRAK/ 


prouueed  by   the  rre  ticcess  cr  is   coaciaed  with   any  FCFIHAN 
the  user  may  have  written,  and  then  it  is  compiled,   linked, 


and  executed. 

different  tr on  I  ems,   it  is  necessary 


LO     * 


r  i  t  e  t  n  e 


sucr.  a  v*ay  tnat  new 


ita  can 


e  i:../ui  a . 


to  ms ur e  mat 


command  file  (JCL,  macro,   etc 


iOfeS  n o t 


..  <t    -:  .'.  C 


tdi-xt  r  l  c  ^  r  a  m  lixc,  i  xi  e  ccoc:iii.dti3u  r  e  t  w  e  e  r  P  r.  -  . 
the  I  #31  library  criers  jar.;  advantages  to  cne  aS<.i 
wnicn  are  mgnly  scugr.  t  in  t^e  Program  Lirrary  en  a  d 
tion  c en  era  tor. 


1 .   id  vantages  of  FECI RAN 

Ihe   advantages  or   PROTEAN  are   extensive,   sc   the 
iolicwir-  suggest  onl_,  a  few  of  the  more  dominate  issues; 

-  Formal  programnin^  Knowledge  is  not  required  for  ap- 
plications that  can  be  dene  using  PROTEAN  statements 
aicne  . 

'-  FORTRAN  can  he  easily  intermixed  with  PROTEAN  state- 
ments, allowing  a  tailored  approach  to  problem  sciv- 
ing,  for  the  benefit  ex  the  experienced  user. 

-  Based  on  proven  algorithms  from  the  I  MS  I  Library,  it 
provides  users  kith  tested,  reliable  metnods  fcr  prcb- 
iea  solving. 

-  PRCTRAN  is  powerful,  flexible  and  ease  to  use.   It  has 
■accurate  and  informative  error   messages  and  it  allows 

unrestricted  access  to  FORTRAN  for   specialized   local 
requirements. 

-  It  allows  user  to  specify  a  programming  prchlen  in 
alternate  ways. 
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-  (J  s  €  I  d  oc  u  m  en  t  i  c  r.  in  m  ac  ti  i  n  e  r  =  a  o  a*,  is  :oii  1=  is#e 
availsrie  to  tit  system  ii^icjciiic  rs.  This  aJtlcws 
them    to    generate   a    'Help1    xaciiicy    for    their    users. 

2  .       £  u  in  g  ar  y 

lie  intent  ci  this  section  is  tc  emphasize  that 
there  is  a  marketable  need  fcr  software  products,  such  as 
the    amplication    generator.  tvore    importantly,  vher.    c:ii:;c: 

with  a  iic^rai  Library,  it  rroviies  a  more  functicr.ai 
product  ior  the  user  and  his  working  environment.  Ihe  _v3_ 
library  should  te  viewed  'as  a  product  wmen  provides  scm: 
lesser. s    tc    Le    learned. 
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VI.     IxNLZXING    AND    IZTRIZVA1     FECtf    THE    PRCGInAd    LIESA5Y 


Ihe    Program    library      offers    mucxi    to    the    user 
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negated,   n  tne   asti  can  not  access   ana  retrieve 

much  raster   than  the  time   retailed  to  writs   an  e3uivaier 


.r.is  sparer,   and. 


trie  va. 


-IOC  cSS 


«orxirc    environment    cendu* 


v e    to    c o t n    emcienc" 


tivity.         The      l^jorai^.    should    re 
ti.u'iti     (i»e. ,     routine    ar.  u     -rcgrams)       a 
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tOOii      lifiJCS     W1J.J.         a-Ll€Vl 


3  r 


tne 


iiCcJU 


r    a 
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aj.lv    rewrite    programs      ror    eacc    new    a^plica tier.  i;:t    tru-.- 

effec tiveress  is  exhibited  by  tne  user's  familiarity  wit:. 
the  entities  that  aie  available  and  now  the}  are  caiiei. 
Thus,  the  3oal  is  tc  provide  a  Program  Library  which  strvej 
its  cur^cse  best  by  3iving  the  user  a  iast  way  tc  lccat-.. 
entities.         The    concepts      mentioned   are    not    new,  tney    nave 

beer,  studied  extensively  by  Melinda  Theders  [Her.  23],  with 
results  that  could  make  tne  Program  Library  highly  errec- 
tive.  Ttedens'  results  provide  a  conceptual  view  consistent 
kith    the    idea    or    a    Prcgram    Library. 

lie  Ircgram  library  has  been  designed  to  support  a  hier- 
archical structure  consisting  of  multiple  levels  of 
libraries,  eacn  accessirle  by  the  user.  Tne  entities  within 
tne  library  are  well  documented  in  a  descriptive  manner. 
Thus,  the  documentation  can  re  used  to  assist  the  user  with 
issues  of  form,  parameter  passing  techniques,  error  handling 
procedures  and  any  other  standard  features  pertinent  tc  the 
library  and  its  manipulation.  These  and  other  features  must 
be  maintained  to  make  the  library  effective,  out  tr.e  effi- 
ciency   cf    the   Prcgran    Lib'ra  ry    is    more    dependent    on    the    speed 


,ith    which    the       library    entities    can    b^    s<=ar 


^  i.—  _» 


user.  Thed«=ns  suggests  that  a  soztvare  proauct  11  associa- 
tion with  the  Prograi  Library  he  ised  tc  4»eip  the  ussca 
access  and  retrieve  the  needed  routines  and  to  ei:lair.  i\z« 
they    should    he    used. 


2.       HEE2Ex    EEFEEENCI    GOIDE 


[Eef.  22]  introduces  the  ccncept  of  a  Library  ?er=renc- 
Guiie.  The   Eefererce      Guide      couid      be    an      on-line       ~J-=zy 

I  r  o  j  r  a  r. ,  a  traditional  a  a  a  u  a  1  tnat  e  a  c  n  r  o  -  r  a  .t.  :.  e  r  c  a  r.  ••  -  -:  . 
en    his       (her)       desk,         or   a    cc  urma  tion      or    not:..  Jcz    cn^ 

p  ur  _:  c  s  e  or  t  hi  s  thesis  /  the  on-line  ^uery  pro3rar  w  i  1  x  :  ^ 
the  type  reference  guide  descrired.  Ine  Reference  3uid-= 
should  he  viewed  as  a  software  product  which  ^-reviles  an 
interface    between    the    user    and    the    Program    Lirrary. 

Ihe  Eeference  Guide,  xike  the  Program  Library,  has  ta.e.. 
some  ideas  from  the  crganizaticn  of  the  traditional  library* 
Cne  feature  in  particular  is  in  the  or ^aniza tier  ana 
indexing    which       functions   like    a      card   catalog.  Ihe    index 

snould  censist  of  Keywords  that  are  used  when  calling  u£  a 
selection    of   on-line    files.  This      snouid    be    easily    relate! 

to  a  user  who  is  fairiiiar  with  sucii  traditional  indexing 
tools    as      the   KTwIC     (key- wor d-in-context)  which    accompanies 

tne    ItSl    library.  Ihe   indexing    of    files      makes    the    user's 

task  cf  locating  entities  much  easier  than  writing  then,  but 
for  the  user  to  make  use  or  the  Reference  Guide,  it  rust 
also  be  sinple  to  use.  Tc  maintain  a  hi^n  decree  of 
simplicity,  the  descripticn  of  what  the  entities  are 
designed  for  should  he  organized;  tne  organization  should  be 
such  that  the  descriptions  are  kept  to  a  few  lines  or  sters. 
Ey  maintaining  short  descriptions,  tne  user  is  ret  begged 
down    with    massive      aucunts    cf    information    which      lessens    the 


G  1 


decree  oi  urders  tan  u  irg  wnile  mcrtasin.,  the  user's  ieeiirg 
cf  ccajiexity.  -  The  snort  descriptions  can  ::  treated  as 
iiicij,  cerirec  nou  jicS  whi.cn  can  be  ac  Jiiieu  to  .icscii.5  the 
entities    that    have    aisc    beer-    acdined. 

TAith  the  documentation  playing  sucn  a  aajor  rcie  1  r.  the 
effectiveness  of  the  tiojrai  Library,  some  cf  the  concerns 
enserved  in  [Ref.  24"  Suoald  he  rtiteratec.  One  ccr.cern  is 
that    the    functional      descriptions    of    how    an      entitv    rer:;_::~ 


its    furcticr      internally    shcuid 


aiiaer.  ,       so    as 


tC        3  ^  ^  W 


fxexiriiity  in  writirg  future  versions  or  the  entities 
documentation   s c o ul d   aioo  c c n t a i n  a   1 e s c r i r t i o n 


inputs  ar.a  cutouts, 


.articuiar. 


^  >jl  j.a  ^  ^     a ...  u 


an ;es    o: 


values.  Finally,  the  documentation  should  inciud' 
tions  of  the  side  effects  or  usir-  the  entities  (e.g.,  wr.ici. 
registers  get  destrcyed,  wnich  woik  fields  arc  used  jr.^ 
wnich  status  flags  are  affected).  In e  user  should  re  arlc 
to  use  these  items  cf  informaticn  cc  avoiu  having  to  examine 
the  cede  that  performs  the  function. 

The  library  Reference  Guide  snould  ne  task  oriented  and 
the  techniques  cf  stepwise  refinement  should  h€  usee  to 
descrihe  the  entities  (from  the  most,  general  to  the  mere 
detailed  levels).  The  importance  placed  en  testing  the 
entities  cf  a  Program  library  should  be  extended  tc  the 
documentation  used  tc  descrihe  the  lihrary  guide.  The  accu- 
racy cf  the  library  decumen tation   could  be  a  deciding  joint 


as  tc  whether  the  Hilary's  resources  are  used. 


ne    actua^ 


testing  shcuid  involve  checking  for  omitted  infcrmaticr, 
infornaticr  present  in  the  wrong  order,  typographical 
errors,  and  ambiguous  descriptions.  Each  time  tnere  is  an 
update,  or  new  additicn  to  the  ^uide,  the  above  mentioned 
tests  shcuid  be  accomplished.  The  dates  oi  these  medifica- 
tions  shcuid  alsc  be  .kept  on  file,  so  as  to  assist  the  user 
in      identifying    the      changes    as      related      tc    his       particular 
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task.         therefore,     tie    user    will    not    ne    required    tc    read    the 
entire   iifcrary,     just    that   in    his    or    her    area    cf    concern. 


1  .      Cn-Iin e 


uer 


Pr cir am 


v.  XJ~  L±n  t     ^utt  j     r  ^  o  -j  i.  a  ii. 

Cne  approach  to  Iheders'  on-line  auer}'  program  is  to 
have  it  perrora  search  and  retrieve  processes  or.  the  Frcgra* 
I i b r a r y   with  the   use  of   keywords.    An   example  shewn   in 

f  r  ca  the  -er s~  ec- 


rigure  o.1  can  he  described   as  follows 


tiv 


cf  the  user  who  requires   a  routine, 


z  at    is    a:. 


c  i  *  -  ».  c  - 


with    the    specifics    of    the   routine     (i.e.,     what    it    is 

to    jC,    what    are    its    ].  ara^^t  ers ,    wuich    routines    io^s    it    caii, 

etc.)  ,    a    keyword   or    list   of    keywords    car.    i 


c  a  i„L  a  « 


User 's    Query 

The  user  can  then  establish  a  juerj  from  the  identi- 
fied (user's  best  selection)  keywords.  The  user's  ^uerv  ca/. 
Le  organized  using  different  methods.  One  method  consistent 
witn  [Eef.  23],  suggests  that  every  routine  in  tne  Program 
Library  he  described  in  snort  sentences  containing  a 
subject,  a  verb,  and  possibly  a  modifier.  Tne  words  in  t^e 
sentence  which  are  net  keywords  (e.g.,  and,  or,  for,  a,  the, 
etc.)  will  he  deselected  by  the  translator.  Another  icethod 
is  tc  provide  ,  keywerds  with  nooiean  connectives;  ior 
example,  given  three  keywerds  (A,  3,  C) ,  they  can  ce 
processed    t\    the   translator       as    A   or     (B    and    C) .  A    scan    of 

the  library  file  would  identify  either  keyword  A  or  else 
both  keywords  B  and  C.  A  more  likely  strategy  uses  inverted 
indexes  ^hich,  fcr  each  of  the  three  keywords,  contain  lists 
cf  the  document  references  exhibiting  the  particular 
keyword.  The  search  process  for  the  ^uery  tnen  performs  an 
intersection  of  the  document  reference  lists  corresponding 
to  index  terms  B  and  C  to  identify  items  appearing  on  beta 
lists.         The  resulting    list    is    then    merged    with    the    document 


library    Btiereiicc    a  aide 
(or- lint    juei^    program) 


QUEEY 

IE  ANSIA1CS 


KEYEC5D 

S IGE AGE 


TErwl 
CCUPAEATOE 


facets}!  :\j  i 

1 1 E  E  A  f  i    j  j 


ill.: 


!  I 

!  i 


!    1 


Figure    6.1         Hatching    ox    User's    Queries 
Against    Erogram    Library    Entities. 


reierecce  list  corresponding  to  term  A  to  ottain  ail  items 
located  either  en.  the  A  list  cr  on  the  combined  E  and  C 
list.  Independent  of  the  irethcd  used,  the  translator  will 
le  reguired  to  handle  the  guery.  The  latter  method  ierre- 
sents  a  guick  search  facility,  cnus  it  will  re  usee  to 
further    explain    Figure    6.1. 

£uery    Translator 

Ihe  guery  translator's  function  is  to  format 
keywords  {i.e. ,  break  the  uuery  down  into  its  component 
parts,  (individual  terms  and  boolean  connectives)}  for.  input 
to    a    temporary       storage     (e.g.,       a    memory).  The    translator 
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must  alsc  maintain  the  guerv  intact,  so  chat  it:  cd.:  ~e  ust=d 
later  as  a"  check  acainst  the  routines  and  ti:e  keywords 
let jrcei  tc-the  user.  The  keywords  are  maintained  to  alio* 
tne  resclver  to  perfcrm  its  functions. 

Keyword  Storage 

The  keyword  storage  acts  as  a  memory  for  storing 
distinct  terms  (keywcids)  temporarily  in  a  predefined  r:rmac 
(i.e.,  parallel  with  n  cells  for  n  terms).  The  keywords 
should  re  held  in  storage  until  the  search  frocess  has  :ee.i 
completed  or  until  deselected  by  tne  user.  Tne  fcrmat  or 
the  terms  is  important  to  the  next  ste£  of  tne  r recess  whj.cn 
uses  the  term  comparator. 

Term  Comparator  and  Document 

The  comparator  matches  the  identifying  information 
from  the  document  library  file  against  tne  guery  tens.  To 
avoid  having  to  page  tnrougn  the  entire  linrary  file,  the 
ccmtaratcr  receives  only  tne  keywords  associated  with  t he 
routine's  function.  The  comparator  should  re  built  to 
handle  truncated  terms  (with  missing  prefixes  as  well  as 
missing  suffixes  and  so-called  "don't  care"  characters). 
With  this  facility  the  question  of  ambiguity  must  be 
addressed.  Figure  6.2  shows  a  hierarchy  of.  Keywords,  asso- 
ciated with  similar,  tut  different  routines.  The  ambiguity 
becomes  a  factor  when  the  routines  are  searched  using  the 
truncated  keyword,  thus  calling  'the  routine  INIT  cr  INIT* 
could  ieturn  either  cf  the  structures.  To  avoid  ambiguity 
the  ccmrarator  will  return  both  routines,  giving  the 
resolver  cr  eventually  the  user,  the  option  of  selecting  the 
appropriate  routine.  The  terms  returned  to  the  comparator 
are  pcssitle  because,  as  Thedtns  suggests,  the  library  guide 
is  constructed  such  that  each  entity  (i.e.,  prccram, 
routine,  etc.)  is  preceded  ny  documentation  information 
consistent  with   a  design  template.     The  template   will  be 
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Figure  6.1    Hierarchy  of  Keywords. 
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designed  with  a  consistent  format  so 
jro.;  ran  or  the  programmer  when  required,  to  se^ec 
inf or n a ticn  needed  without  sciclling  the  entire  routin 
example    ex    fossirle    template    heading    migut    include: 

Description 
Keyword 
Fcimat 

Cr i gin at cr/P rcjec  t 
Cn  Incuts 
Cd  Eeturr 
On  Zrior 
Ci  Calls 
5ec uixement 
Ot tiers 
Special  Case 
Exanf les 
Op  dated 
•.  Fcurd  In 
See  Also 

US€S 
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routines  which  will  ret  ase  all  of  the  naadinus,  the  or.es 
that  ccr.  't  apply  shculu  oe  deleted.  Svi.th  trie  "uses"  and 
"found  in"  heading  the  search  process  can  take  on  the 
appearance      of    a      hierarchical      structure.  Ihis      ar^rcacn, 

snown  in  Figure  6.3,  can  easily  he  adarted  for  use  with  the 
hierarchical  structure  used  in  the  Prouram  Lihrarj  (i.e., 
the  tot  c-  the  documentation  sxiouj.1  point  in  che  ri:ht 
dirccticr.  and  the  search  of  subsequent  lower  layers  should 
provide    ncre  and   more    detail). 
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Figure  6.3    Hierarchy  of  Reference  Guide  Documentaticn. 
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libraiy    terns.         Should    a    retained   routine    not    be    consistent 
with    the    user's      ^uery,      it    is   deselected..  Ihis    leans    the 

user    will    net      necessarily    see    all    the      routines    selectee    by 


the    c  c  c  :  a i a  t  cr .      Once    the  checking    staoe    has    ce 


e  e  n    con 


the    results    are    sent    to    the    output    aev. 
cr    a    r i u e    pr inter)  . 

Search    Output 


LCttiLai 


:  j 


Ice  actual  oitput  win  consist  or  a  xist  .. . 
h  j  n  a  n  e  ,  with  a  shcit  descriptive  abstract  j  r  t :.  -  :;i::.;.'. 
luncticn  anc  o  t  r.t  r  related  k  e  y  w  or  u  s .  Since  tee  c  c  c  u  i  :  n  ■ 
library  file  only  certains  the  header  template  c a  thee  tea., 
the  decuire  r.  tation  plus  coae,  the  user  snouid  ce  arle  to  vie* 
the  repairing  documer.ta tion  of  the  routine.  This  cculi  ~- 
compared  tc  a  "rrowsinj"  facility  which  provides  ieed~ac.\ 
ror    guerj    refinement. 

Fetrie va  1 

Cnce  the  user  nas  locatea  tne  desired  routine  name 
and  is  confident  that  it  does  the  required  task,  he  cr  she 
can  tag  the  routine  tcr  retrieval  at  tne  end  or  tee  trewsm-.j 
session  cr  initiate  '  the  retrieval  at  that  time.  ^ner.  the 
routine  has  heen  ta3ied  ror  retrieval,  its  location  witr.ir 
the  Eiocian;  Library  is  identified  (i.e.,  rointer  directs  the 
systei  tc  its  lecatien  in  aeirory) .  Ine  user  can  new  he 
prompted  as  to  whether  the  routine  is  to  ce  retrieved  (i.e., 
placed    ir.      the    user's    file)  .  At    this    point      the    retrieval 


process      will      permit      authorized         users 


continue   t  h e 


browsing  process  down   to  the  actual  source   code  level,  it 

will  alsc  allow  updating  (i.e.,  additions  and  deletions)  ana 

nest  an  3  manipulation  permitted  in  the  prouran  library.  Ine 

retrieval   is   similar  to   the   search   process  in   tnat  it 
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depends    ieaviiy    en       the    names    and    functions      of.    the    entities 


in    the    prociaa    library,       a    la 


uisti action    ret ween    tne    cwo 

when  t  :i  e  lie:  1  n v :.<  =  ;  the 
retrieval  process  he  cr  she  knows  the  identity  01  the  entity 
and    is    z airly   sure    of    its   location    in    the    program    library. 

trier  to  using  the  "rstiicVdi  inechanisi  the  user 
snoulc  tc  familiar  i»icu  tne  fjierarcnj.caj.  structure  or  cue 
rio-iai    library.  A    3 i ia 1 1  iiied      exaj^it    oh      *r.  at    the       j^-j 

i;.oaid  ttviiion  in  the  structure  and  w  a  a  t  procedure  c  o  u  id  r,  - 
used  tc  retrieve  a  routine  at  different  levels  -ill  de 
presetted.  First,  the  user  should  nave,  a  general  urder- 
s tan  din j    of    the    library'?    structure    cor    a    s^cmc    iacx^r. ez- 


taticr.         The    foliowiru.    should       provide    a    -, 


cr  the  structure.  The  structure  can  re  viewed  as  certain.-..; 
entities  which  are  refered  to  as  its  aembsrs,  Ihe  Octic^ro 
ci  the  structure  are  ordered  hierarchically.  Ihe  lair. 
aeniLers  at  the  higier  levels  or  the  library  are  ca^-iei 
supersets  to  any  member  at  a  lower  level  and  iiKewise  ah/ 
member  at  the  lewer  level  is  called  a  sunset  or  the  cipher 
levels. 

A  structure  should  define  its  organization  and  the 
rames  of  the  memners  on  each  level  in  the  structure.  \ 
general    fern   of    the    structure    could    include: 

-  the    naire   of"  the    meaner    at    the    hignest    level 

-  the   names    and    attributes    cf    its    members    ana 

-  a    level   identifier    for    eacu    name    tc    define    its    level    in 
hierarchical    order. 

Examples    of    this      structural    form  can    be    seen      in    the    record 

structure    cf   a       PASCAI    program    or  the       structure    declaration 

cf    a    EI /I    program.       1c    illustrate  what    the    user    could    expect 

wnen  retrieving  a  .routine  rrom  the  Program  Library  the 
follcwinc    scenario    is    proposed. 
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So    re3in      the    scenario,      a      pro<_ 
facilities     (i.e.,         hardware    and      s  or  t  w  a  r  e ) 

i»orkstaticn.      He   o 


a  r. c e r    ii 


ve  r 


t  e  r.  1 1  i  _ 


££€  is  exrectea  to  ta/ie  tnese  :ac;i;t2£  = 
and  establish  a  workstation  ca^aiic  or  assisting  in  accca- 
clishir^  their  task  cr  job.  Cne  lajor  asset  included  ir  the 
facilities    is   a    Program    Library.  The    library    contains    the 


ines 


re  :  r  a  .?  s 


routines   tc   build   essential   programs. 

consist  cr  the    appropriate  routines   to  make   a  «or as  ratio*. 

responsive  to  the  pr  c  gramme  r  '  s  requirements. 


tne 


daiic; 


The  facilities  provided  to 
sia^idi  tc  tnose  of  a  SUM  workstation  and  tnus  induce: 
capaiiJiti  to  operate  in  a  catch  or  an  interactive  environ- 
ment, the  ability  tc  use  various  input  a e vices  (e.  =.  ,  "•"•> 
joystick,  the  mouse,  tn«  tracx  luj.1  ana  the  toucn  screen)  , 
the  anility  to  produce  eitcer  color  or  monochrome  Uisclays 
(with  varying  hues  arc  x-y  addressing  and  tuc  facility  to 
res per d  to  a  nuiber  cf 
DBMS,    Graphics,    Gaines   and   Inventory    Manage  men 


.irrerent  s o r  t w a r e   t a c k a  g e s  ( e 


Ihe  programme!  must  new  establish  the  ccrre 


ities  tc  allow  the  wcrkstation  the  capably  or  performing  the 
desired  task.  The  necessary  data  can  ce  retrieved  iron  the 
Ero^ram  library  as  shewn  in  the  Hierarchical  structure  dl 
figure  6.4.  In  the  example,  the  programmer  requires  a 
graphics  package,  which  is  user  interactive,  with  a  color 
display  ccn  trollaole  with  a  mouse.    The  routines  s»hich  will 


iiv 


these  and   other  features   are  stored   in  the 


rear am 


library  until  retrieved  by  the  programmer  for  insertion  into 
a  pr  c  gran . 


rigtre  6.5  uses   lot  notation  to  illustrate  'no*    th. 
programmer  can   retrieve  routines  from  the   Program  licraiy 
With  the   use  cf  a  library   prempt  (Library  >) 


the  various 


roitir.es    car   be    located    and    retrieved    ia    shewn.         Ihe    a  as  red 

lines    arcund    the      routines    imply    tiiat 

re    atle    tc    retrieve    a    routine    directly    without 

its         inreciate         superset,  ror         example,  Library 

lib. Gra^ hies. Moveto    can      be    used    to      retrieve    the       lew    level 

routine    £cveto,     with  cut    using    routines    at    the    Mid    levels. 

Ambiguities  can  arise  when  referencing  tre  zer~ers 
cr  a  structure  because  the  rane  cr  a  clearer  ca:\  occur  i;  the 
name  tc  trore  than  one  superset.  To  resolve  such  ambigui- 
ties, gualiiied  names  to  reference  members  or  the  iih.ary 
structure,      can    be    used.  In      a    ^uaiiiici    name,       the    :=;:=: 

name  is  preceded  by  a  list  cf  routine  names  in  ari  ::.  .A:*.- 
crder      i:y    levels,         each    followed      by    a      period.  Ihe      oily 

routine  rases  required  are  tuose  that  determine  a  iT.r_.ue- 
reference  tc  the  member  name.  For  example,  lr,  the  r  c*  i  ;  *  ^:.  ; 
structure 

1  Graphic 

2  Interactive 
2  Cclor 
2  Mouse 
4  Ec veto 
4  lineto 
4  Erawtext 
2  E  a  t  c  h 
2  Cclcr 

4  Eisplay 
5  Mcveto 
5  lineto 
5  Erawtext 


High   Level    Li.br airy 

i       J  "         I  I 

ZEV.S    |       J    Gravities    1  J       Gaaes 


J J 


1  I 


j.  n.  venter  y 

'i  a  Li  a  g  e  z  e ."  t 


i  i 

1     ! 
I     l 


y.ic    itvel    libraries 


i  i 


j     Interactive 


|   Eatc-i   J 


I     \ 


J    J  1 

i     j  X-i  Axis   J 
J    ]  Relation   j 


Mcnocbro je 


i   i 


i  Jci 

1   S  t  2  CA 
J 


House  1 


J   iCilC. 

I  Screen 


j  ; 

!  I 


Hues  | 


Irack  j 
Ball   | 


Mc veto 


low  Level  Library 


Li netc 


raw  text 


Program  Library 


Figure  6.4    Example  Hierarchy 
of  a  possible  Program  Library. 
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i    Graphic      j 


Library    >    Lib.Grapnic 


Eatch 


Interactive  |    >  Lib. Graphic. Interactive  i 


>  i-  i  D  .  'j  r  a  p  .i  J.  C  .  X  .".  z  - 
.lO  JSc" 


Erav.  text 


L  in  e  t  c 


I  o  v  e  1 1 


>    Lib.  Graphic  Interactive.  I 
/ioase .  M eve to 


figure    6.5         Example    of    a    Retrieval    Process. 

a  reference  to  Mcvetc,  Lineto  cr  Drawtext,  or  Graphic. Color 
cr  Graphic. tfovetc  is  ambiguous  alon^  with  a  few  other  rela- 
tions. The  qualified  raines  In terac ti ve. C c  lcr  or 
Interactive . Mo  veto ,  cr  Eatch. Moveto  uniquely  identify  the 
library    routines.      The    fully    qualified    names    would    re 

Graphic. Interactive. Color 

Graphic.3atch.Colcr 

Graphic. Interactive. Mouse. acveto 

Graphic. Batch. Display.  M eve to 

each  should  hel^  to  alleviate  any  amnicuities.  Tc  shorten 
the      user's  "request      truncated    rames      can    re      used,       hut      as 
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iiiustiatec    pr  e  v  io  u  s  1  j    the    ctr.e:    f  o ; 

I  £  3  C  1  V  €  d  . 


or    airi-  Jit, 


E.        SCENES 

The  anticipated  :cai  of  the  Library  Reference  Guide  is 
to  siijiify  the  search  an  retrieval  iicji  and  addi tiers  to 
the       riccrai   Library.  Simplicity      oz      both    issaee      sh culm 

improve  cr.  the  user's  efficiercy,  lessen  the  amount  of  txr- 
•asted  locxina  for  the  best  entity,  improve  t/ie  -seri 
ariiity  tc  write  prc-rams  and  finally  and  oost  in-crtar.t, 
increase    the    user's    product  ivit  y  . 
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VII.     1KI     AIA    PROGRAMING    LANGOJGE    AND    THE    PRCGRAM    LIEfiAILS 

Gccuen'[Ref.  25],  discuises  tne  cost  of  sore  ware  tec  is: 
"It  appears  that  each  successive  generation  of  sort -are 
development  tools  has  teen  significantly  tore  expensive  than 
the  -xevicus  one.  However,  these  tools  die  still  u.uch  j.<=sj 
expensive    than    ccr re sr ondin g    hardware    tools,      sues    as    fabri- 


cation     lines."      Ever      with    this      k n o w  1  e d - 


tne  re 


great  reluctance  to  invest  significant  amounts  or  ncr.ey  ir.to 
research  and  dev eloquent  for  software  toois.  In  fact,  e  ....:> 
ic  a  as  been  uiscovertd  that  a  c  s  t  of  the  cost  of  real,  s  y  s  -.  e  i  s 
row  lies  ie  software  rataer  than  uardware,  the  r  =  I  ic  *  a  r.c-- 
invest  heccies  even  aore  evident.  Ihere  are  sere  rc^erul 
signs  which  have  shewn  that  tne  Japanese  "sortware  facto- 
ries" are  actually  ca^arie  of  achieving  rates  of  reusability 
ranging  frca  60%  to  £C9?  [Ref.  25].  Also,  scce  'J.  i.  irdjo- 
tries  and  specifically  tne  Department  ol  Defense  (Dol)  have 
begun  tc  invest  in  the  field  of  software  productivity, 
EoD's  erforts  have  teen  extensively  geared  tc  tne  dev€lcr- 
nent  cf  the  programming  language  "Ada,"  wnich  is  designed  in 
accordance  with  reguirements  established  by  the  DoD. 

I  he  reguirements  call  for  a  language  with  consider'arle 
expressive  power  covering  a  wide  application  domain.  As  a 
result,  the  language  includes  facilities  offered  by  clas- 
sical languages  such  as  Pascal  as  well  as  facilities  cf ten 
found  only  in  specialized  languages.  Thus,  the  language  is 
a  modem  algorithmic  language  witn  usual  control  structures 
and  with  the  ability  to  define  types  and  subprograms.  It 
also  serves  the  need  cf  modularity,  whereby  data,  types,  and 
subprograms  can  he  "packaged." 
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The  fcui  program  cnits  cf   Ada  are  suhcrojrdJS/ 
units,   tasK  units,    ana  generic  units.    Ihe   two  units  c 
special  interest  for  a  Software  Licrai  •'  are  the  t-acXace  uri 


and  the  ceneric  unit. 


pacK.a.j€  is  defined  as  a  cciicCti; 


I    generic  unit   is  a  tdr- 


cf  icgically  related   entities. 

late,  which  is  parameterized  or  not.   Corresponding  (ncrgen- 

eric)   subprograms  cl    racka.j£s  can   be  obtained   frcs  t..ea. 


1  h c  resulting 


r  o  g  r  a  a  mi  t  s  a  r  i 


instances  or 


^  j.  i  .i*.<jj. 


generic    uiit   and    thus,    forms    01    "instantiation." 

An    e x a i t ie    cf    h c v   Ada   suppcrts    the    ? r o  - r a i    1 1: r a . 


x  ~       i.  ... 


tne    vav    th 


su 


a  a 


c  ^ 


that    each    er.  tit 


m 


tnc     cl'O  J  tail     i-i £ j.  a 


;a u i e 5    template      to 

4-1 


retrievirg      tne    entities      f  c  r 


cii  as  a  means  or  searc^ir--  an  _ 
jcsiii/ii  uioQii lCaiicr.  (i.e., 
dele  tier,  acditicn  arc  updating)  .  I'aat  tne  3eneric  rrc^ia: 
unit  ^icvides  is  the  ability  to  net  only  search  an: 
retrieve,  hut  also  tc  ninimize  the  modif ica ticn.  one  met  nor. 
in  which  Ada  exhibits  this  is  snown  oeiow  [fief.  2],  we ere  i 
sub -re cram  is  create c  that  exchanges  two  elements  cz  an 
integer    type; 

procedure    INT2GER__EXCHANGE  (EIES1,    SECOND;    in    out    INIZGER)is 

1ECECHA5Y  ;  INTEGER; 
begii 

lEHrCEAEY  ;=  FIR  SI; 

FIESl      ;=  SECOD; 

SECCKE     ;=  IEMICEAEY; 
end  INIK-ES_EXCHANGE  ; 

Cnce  this  application  is  established  ether  types  or 
elements  maj  be  excharged  without  creating  a  new  subprcgram 
for  each  instance.  With  tne  algoritnm  oeing  identical  in 
ail  cases,  the  similar  operations  may  be  ractored  cut  bj 
adding  the  followirg  generic  unit  tc  the  procedure 
speci  fie  aticn; 


b& 


generic 

type    EIEttENT    is    private; 
procedure    EXCHANGE     (IIE5T,     SECOND    :    in    oat    ELEhiENT)  ; 

Ihe    hcdy   ncti  becomes: 

procedure    EXCHANGE     {EIF.ST,     SECOND     :     in    oat    ELEMENT)     as 

HKfCHASY    :     EL 13  EST; 
begin 

1IMSCEAFY    :=    FIfiSI; 

FIFS1  :=    SECCKD; 

SECCiiL  :=    XEKECEAnx; 

end    EXCHANGE;, 

Ihe  significant  portion  of  this  suDpro-id^  s  -ec-iics:  ior. 
is  the  addition  or  a  prefix ,  caiied  the  "generic  part,"  c;^; 
defines    ail    of    the    generic      parameters     (if    any) .  Ihe    arcve 

two  algorithms  have  the  same  identical  nody  with  the  excep- 
tion cf  the  data  type  which  is  handled  by  tne  generic  -art. 
This  process,  as  shoi»r,  allows  the  programmer  the  ability  to 
make  use  cf  the  existing  body  cf  a  program  unit,  instead  of 
writirg  one  from  scratch.  Sc  with  this  method,  the  mcdiri- 
caticrs  are  mainly  performed  en  the  specir ication  (i.e.,  the 
generic  part),  horeruiiy  minimizing  the  degree  or  change 
necessar}.  The  Program  Library  would  manipulate  its  -enti- 
ties ic  a  similar  manner,  making  it  at  least  as  reusai.it  as 
Ada    lakes    its    generic    packages. 

Since  generic  units  are  just  templates,  they  are  not 
executarde,    and    so    they    may    net    be    used    directly.  Eut    they 

create  instances  of  the  generic  unit.  Thus,  the  instantia- 
tion cf  the  generic  unit  makes  the  subprogram  or  the  package 
sufficiently  easy  to  identify  and  comDine  with  other  units. 
Ther€icre,  the  gcals  and  concepts  of  tne  Program  Library  are 
supported    by   the      Ada    program    language   and      although    Ada    may 


not    represent      the    best    .anj aa  :e 
support    the    Fro g ram    library    cere 


01      t."fc      il  0  Z  1  _  V  / 

,    3=6    i Ref .    25 ] 


with  £Ref.  25]  and  [Ref.  2\,  tne  aforenenticr.ed  £xazries 
are  ir  a  a  e  clear  and  the  Progran  Library  is  established  aa-  c: 
p oten tialiy  feasible  software  i.'-°^ucb-  Even  nore  supportive 
is  the  reference  made  tc  the  organization  of  a  "Ada  Program 
library."  2he  refererce  waxes  siairiar  rrocosals  tc  those  of 
this  thesis  in  the  area  of  liirarj  construction  arc  :rcia- 
tion.  Specifically  it  suggests  a  hierarcai  :a  l  cl-ssiiiCi- 
1 1  o  n    s  c  n  e  ill  e  t    «*  1 1  n    Jiiicrciit    it  vds    or    d  e  t  a  i  j.    a  n  o    icr  u  j  ^  -c  ii, 


a..  J      '« 


i  t  h   each   e  r.  t  i  t 


aCCcSS  i^xt      £ 


tnat      tne      prcfosaxs    or  fere 


k  e  .'  w  o 


arc 


anywhere   near   ready  for   implementation. 

concepts  arc  not   that  reuotc  and  at   _cas 

(i.t./   the  DoD)    is  willing  to  risk  tne 


jr.e  or^r. 


a  no 


investigate  the  ^otertiai  tc  achieve  these  conceptual  -, 
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VIII.  NGN  CODE  PRODUCTS  IN  SOFTWARE  LIzRkRlLS 

Even  with  the  Software  Library  representing  an  tiieciive 
reusable  software  product,  one  must  as*,  ii  that  is  enough  to 

The   S  o  f  t  w  a  z  2 


encourage   effective   software  development 
library  has  been  represented  by  proaucts  ( 


e . 


H  '   I 


:as 


Library)  designed  tc  enhance  reusability  of  cede.  A  x  t  i  ;  u :  .. 
tne  nanacenent  a  r.d  ciganizaticn  of  code  is  critical  t:  the 
futjre  development  cf  reusable  software,  thtic  are  cuter 
software    ficducte      that    are    developed    during      ~--~    iire-cyci%; 

that  have  the  potential  for  reuse.  Ihese  include  zee  i  z  ?:.  t  = . 
ic^juii  e  lent  z,  specif  ication  s,  designs  and  test  plans.  Jt5i 
as  reusability  in  ceding  can  he  used  to  reduce  software 
coding  ccsts,  so  can  reusability  of  software  products  in 
ether  chases  of  the  life-cycle  contribute  to  cost  reduc- 
tions. Each  of  the  concepts  in  tne  conceptual  r  re.; ran 
library  can  be  applied  to  ether  software  products  in  the 
life-cycle . 

Ihe  definition  cf  reusability  aas  placed  tne  eiphasis  on 
tne  carital  returns  cf  a  scftware  product.  If  it  is  mere 
cost  efiective  to  use  existing  designs,  specirica  tions., 
requirements  and  test  plans,  then  tney  should  te  leused. 
Even  with  this  being  the  case,  if  tney  are  not  organized  in 
an  accessible  and  retrievable  manner,  tney  lese  tneir 
reusable  nature.  With  reusability  being  so  important,  this 
issue  aust  te  addressed  as  an  objective  cf  tne  develecisnt 
process  throughout  the  life-cycle.  To  reduce  the  cverall 
cost  of  a  software  product,  all  phases  of  its  life-cycle 
should  inccrporate  methods  and  standards  which  will  sutrcrt 
reusability.  Once  the  software  product  is  postulated  as 
being    reusable,       the    issue    must      be -fully    addressed    then    and 
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Hot     d  t     c  C  I  e        -l  a  t  €1*      -  CdSc     OX      t  h  €         J.  1  X  c  —  J  2  o  ■*■  €  •  H  O  W  €  V  t  l  /  "  ..  -r 

iSi  Jt     CX         XcUSdhiilt}     Si.  Oil  id         TCl     Dc        I0»C6Q     Oli         the      IcSi^Ii/ 

specification      or    any      other      thasa      net    ccspatisis      ;c      the 

repairs j    ar j.iica ti cc  .  Each    jhase      snouid    be      viewed    seta- 

ratclj  and  a  determination  made  as  to  rfhether  reusability  is 
econc  lie  ail}'  feasible.  If  it  is  then  reasauiiitj  shcuiu  he 
inccr cerate  a,  oat  ix"  it  is  net  feasible  it  should  net  be 
ins  is  te  1. 


Finally,         since      leasable    software      ^redacts       cizer 
drprcac;.    tc    lessen  in-    the    eixects      ob     tae    "Soxtwaxe    Cric 
6r.vircr,±t;;ts      en  com  pa  sain.,       tr.is    coi.ee  _-       she  a  la       it 
i  is  n  e  q  «         I  r.  •cS  e    enviicnnd.'cs    s  n  o  u  j.a    n  c    c  en  c  e  r  n  e  c     <■  1 1 .'.    ~ . . 
ex    the    *ixe-cycie    other    than      code.  Ihat    whicn    r.ac    -.: 

been       learned    irc^i       hcrking       with      reusable   cod-      shea  i  a 


applied,    tnis    avcidin 


'reinventinj  o:  t n e  w h 


IX.     CONCLUSION 

The  "software  crisis11  is  real  and  if  the  computer 
industry  is  to  havt  any  impact  ox  reducing  xts  effects, 
software  developers  irust  begin  taxing  concerted  extorts  to 
create      reusable        software      products.  This         thesis      has 

presentee  the  Software  Library  and  its  prototype  the  Prcgra^ 
library  as  -cssir-Ie  reusable  software  produces.  Iletr. cos  of 
majtixc  tie  concept  of  a  Software  library  better  understood 
ry       tit    user      were       discussed.  In  is    was      ace- :.  t  lis :.  =  ; 

coatarisor  cr  the  Software  Library  to  a  traditional  Lirrar, 
and  fcj  relating  it  tc  other  program  iirraries  (t.  articuiarij 
the  IJ*SL  and  the  NAG).  Inese  comparisons  yielded  character- 
istics which  could  re  associated  to  a  auaiity  :c;:.ii^ 
Library . 


if  tne  rrogram  library  nas  a  hierarchical  structure, 
then  the  entities  within  the  library  can  be  easily  accessed 
and  retrieved  by  a  user.  Reusability  is  thus  estanlio;. ed  ac 
a  viable  solution  tc  some  of  the  economic  problems  m  soft- 
ware   development. 

Application  generators  with  similar  hierarchical  struc- 
ture tc  the  frog  ram  library  car  be  used  to  assist  tne  inex- 
perienced user  perform  nis  or  her  task.  Ihe  experienced 
user  should  be  alleged  tc  modify  entities  in  fcctb  the 
Program    Library    and    the    application    generator. 

Ac  cr-lme  guery  program  was  discussed  as  an  interface 
between  the  Program  Library  and  the  user.  Tne  guery  prcgram 
is  '  ere  aprroach  tc  rnnging  reusability  to  the  software 
prod  uc  t. 
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ca   ^rojrajiirij      xancuage    was 
that    su,jpcit       the    ccrcc,:; 


library.         Future   concepts    in    the 
are    in    line    with    the    issues    in    th 


o, 


cescriLc:    as       .-.  avi:. 
a    rc  jsahii      .;ic_,.a, 
Aud   ^ro^raii    library    m.  ic. 
tr.esis    art    rezerencei. 


rinaliy,      the      Scitware    Lurrary    snoui^      include    jiciact; 
iron         t rases      01         tr.e        iire-cy cle        other      than         ceding 
Zoc  uaent  at  i  en,        speciiicatr  ens  ,       re  -  aire  jen  ts  ,         desi-jr.s    a;, 
test      clans    should      te    incorporated      into    the      ccr. c^~    ci 
Soft  war e    Li irar ,  . 
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